5 STa Description

29.2733GPP3GPP EPS AAA interfacesEvolved Packet System (EPS)Release 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 Functionality

5.1.1 General

The STa reference point is defined between a non-3GPP access network and the 3GPP AAA Server or between a non-3GPP access network and the 3GPP AAA Proxy. The definition of the reference point and its functionality is given in 3GPP TS 23.402 [3].

Whether a Non-3GPP access network is Trusted or Untrusted is not a characteristic of the access network; this decision shall be made during the access authentication and authorization procedure executed between the non-3GPP access network and the 3GPP AAA Server. This is implemented by the STa and SWa reference points sharing the same Diameter application and partly sharing the same authentication and authorization procedure. The STa and SWa reference points are clearly distinguished after the exchange of the first authentication and authorization messages, during which trusted/untrusted decision is made by the 3GPP AAA server and this decision is communicated to the non-3GPP access network. The other procedures are specific to the STa and SWa reference points.

The STa reference point shall be used to authenticate and authorize the UE.

The STa reference point may also be used to transport PMIPv6, GTPv2, or MIPv4 FA-CoA mode related mobility parameters in a case the UE attaches to the EPC using the S2a reference point. The procedures specified for EPC access via GTP based S2a are only applicable to trusted WLAN access networks (see clause 16 of 3GPP TS 23.402 [3]).

Additionally the STa reference point may also be used to transport DSMIPv6 related mobility parameters in case the UE attaches to the EPC using the S2c reference point. In particular, in this case the STa reference point may be used for conveying the Home Agent IP address or FQDN from the AAA server to the gateway of the trusted non-3GPP access for Home Agent discovery based on DHCPv6 (see TS 24.303 [13]).

This reference point shall be also used to transport charging-related information and optionally information about IP Mobility Mode Selection.

5.1.2 Procedures Description

5.1.2.1 STa Access Authentication and Authorization

5.1.2.1.1 General

These procedures are transported over Diameter, the Access (Re-)Authentication and Authorization between the trusted non-3GPP access network and the 3GPP AAA Proxy or Server. The STa interface and Diameter application shall be used for authenticating and authorizing the UE for EPC access in PMIPv6, GTPv2, MIPv4 FA-CoA mode or for TWAN access without EPC S2a access (i.e. non-seamless WLAN offload) via trusted non-3GPP accesses and non-3GPP accesses that are decided to be untrusted during the authentication and authorization procedure.

When EAP-AKA’ is used in the STa access authentication and either EPC access in NBM (PMIPv6 or GTPv2) or TWAN access without EPC S2a access (i.e. non-seamless WLAN offload) is used, the trusted non-3GPP access network shall support also the role of the NAS. Specifically, in the case where PMIPv6 is used, the network element of the non-3GPP access network acting as a MAG shall have also the role of the NAS. During the STa access authentication the NAS shall serve as pass-through EAP authenticator.

Diameter usage over the STa interface:

– When EAP is used, the trusted non-3GPP access authentication and authorization procedure shall be mapped to the Diameter-EAP-Request and Diameter-EAP-Answer command codes specified in IETF RFC 4072 [5].

– For (re)authentication procedures, the messaging described below shall be reused.

During the STa Access Authentication and Authorization procedure the non-3GPP access network may provide information on its PMIPv6 or GTPv2 capabilities to the 3GPP AAA Server.

During the STa Access Authentication and Authorization procedure the trusted non-3GPP access network shall provide information on the Access Network Identity (ANID) to the 3GPP AAA Server. Specifically, the TWAN shall set the Access Network Identity as specified in clause 8.1.1.2 of 3GPP TS 24.302 [26] for a WLAN access network.

For a trusted non-3GPP access, the 3GPP AAA Server may perform IP mobility mode selection between NBM and HBM. The 3GPP AAA Server may provide to the trusted non-3GPP access network an indication if either NBM or local IP address assignment (for HBM) shall be used.

For a trusted WLAN access,

– the TWAN should send information on whether it supports TSCM, SCM or MCM or any combination of them to the 3GPP AAA Server as specified in 3GPP TS 23.402 [63]. If it indicates support of the MCM, the TWAN shall also provide the 3GPP AAA Server with the TWAG’s control plane IPv4 address, or IPv6 address or both (if it supports both IPv4 and IPv6), to be sent to the UE and used for WLCP if the MCM is selected.

– if the user is successfully authenticated and authorized for this access, the 3GPP AAA Server:

– shall select either TSCM, SCM or MCM and indicate to the TWAN the selected mode of operation. If the 3GPP AAA Server does not provide such an indication, the TSCM shall be used;

– may either only authorize the user to access to EPC via S2a (i.e. EPC-routed service only), or only authorize the user to access the TWAN without granting access to EPC via S2a (i.e. non-seamless WLAN offload service only), or authorize both EPC-routed and non-seamless WLAN offload services. If the SCM is selected, the 3GPP AAA Server shall indicate to the TWAN its decision to either authorize access to EPC via S2a or only authorize the user to access the TWAN without granting access to EPC via S2a, i.e. not both;

– when authorizing the SCM to be used for EPC access, the 3GPP AAA server shall forward the PDN connectivity parameters received from the UE to the TWAN, i.e. the UE requested PDN type (IPv4, IPv6 or IPv4v6), the attach type (initial attach or handover), optionally the requested APN (if received from the UE) and optionally the Protocol Configuration Options (if received from the UE));

– when authorizing the MCM for EPC access, the 3GPP AAA server shall derive the WLCP key as defined in 3GPP TS 33.402 [19] and shall provide the WLCP key to the TWAN to protect the WLCP signalling.

if the user is successfully authenticated and authorized for this access, the TWAN:

– shall decide the S2a protocol variant to use if access to EPC is authorized and the TWAN decides to establish S2a.

– if the SCM has been authorized to be used for EPC access, the TWAN shall return an indication to the 3GPP AAA Server on whether the requested connectivity has been granted and, if so, also pass on to the 3GPP AAA Server the connectivity parameters to be provided to the UE, i.e. the selected APN, the selected PDN type (IPv4, IPv6 or IPv4v6), the IPv4 address (for PDN type IPv4 or IPv4v6), the IPv6 interface identifier (for PDN type IPv6 or IPv4v6), optionally the Protocol Configuration Options received from the PDN GW once S2a has been established, and the TWAG user plane MAC address. If the requested connectivity has not been granted, the TWAN should provide the 3GPP AAA Server with a cause indicating why the requested connectivity could not be granted; the TWAN may also provide a Session Management back-off timer to be sent to the UE to instruct the UE to not request new PDN connectivity to the same APN for the indicated time.

When authorizing NBM to be used, the 3GPP AAA server shall return NBM related information back to the trusted non-3GPP access network.

During the STa Access Authentication and Authorization procedure, when DSMIPv6 is used, the 3GPP AAA Server may provide a Home Agent IPv6 address (and optionally IPv4 address) or FQDN to the trusted non-3GPP access network. This is needed if the DHCPv6 option for Home Agent address discovery is chosen (see TS 24.303 [13] and IETF RFC 6611 [28]). If the Home Agent IPv6 address or FQDN is not included in the final Authentication and Authorization Answer by the 3GPP AAA server, the trusted non-3GPP access network shall not assign the Home Agent via DHCPv6.

During the STa Access Authentication and Authorization procedure for MIPv4 FA-CoA mode using trusted non-3GPP access, the 3GPP AAA Server may provide the mobility security parameters FA-RK and FA-RK-SPI to the trusted non-3GPP access network.

The User-Name AVP may contain a decorated NAI (as defined in clause 19.3.3 of 3GPP TS 23.003 [14]). In this case the 3GPP AAA Proxy shall process the decorated NAI and support routing of the Diameter request messages based on the decorated NAI as described in IETF RFC 5729 [37].

Based on local policies, EPC access for emergency services over a trusted non-3GPP access is supported as specified in clause 4.5.7.2.1 of 3GPP TS 23.402 [3] for:

– UEs with a valid EPC subscription that are authenticated and authorized for EPC services;

– UEs that are authenticated only;

– UEs with an unauthenticated IMSI; and/or

– UICC-less UEs.

For PMIPv6, GTPv2 and MIPv4 FA-CoA mode trusted non-3GPP accesses, upon mobility between 3GPP and non-3GPP accesses, for the PDNs the UE is already connected, the PDN GW identity for each of the already allocated PDN GW(s) with the corresponding PDN information is provided to the trusted non-3GPP system. The PDN GW identity is a FQDN and/or IP address of the PDN GW. The non-3GPP access network shall use the received PDN GW identity for mobility with IP address preservation or in case of static PDN GW assignment. If a FQDN is provided, the trusted non-3GPP system shall then derive it to IP address according to the selected mobility management protocol.

NOTE: Mobility with IP address preservation is not supported between TWAN and 3GPP access in TSCM.

During the STa Access Authentication and Authorization procedure, the bootstrapping of an ER server in the TWAN with a given root key may be performed, as described in IETF RFC 6696 [55] and 3GPP TS 33.402 [19]. This procedure is used to provide an ER server with the keying material that will be used for further EAP re-authentication procedures using ERP.

Table 5.1.2.1/1: STa Access Authentication and Authorization 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. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15] and shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]. This IE shall include the leading digit used to differentiate between authentication schemes, if it contains a NAI other than an Emergency NAI for Limited Service State.
EAP payload	EAP-payload	M	This IE shall contain the Encapsulated EAP payload used for the UE – 3GPP AAA Server mutual authentication
Authentication Request Type	Auth-Request-Type	M	This IE shall define whether the user is to be authenticated only, authorized only or both. AUTHORIZE_AUTHENTICATE shall be used in this case.
UE Layer-2 address	Calling-Station-ID	M	This IE shall contain the Layer-2 address of the UE.
Supported 3GPP QoS profile	QoS-Capability	O	If the non-3GPP access network supports QoS mechanisms, this information element may be included to contain the access network’s QoS capabilities as defined in IETF RFC 5777 [9].
Mobility Capabilities	MIP6-Feature-Vector	C	This information element shall contain the mobility capabilities of the non-3GPP access network. This information shall be utilized if dynamic mobility mode selection is executed. This information may also be used to decide whether to authorize access to EPC to a user accessing a TWAN. The PMIP6_SUPPORTED flag and/or the GTPv2 SUPPORTED flag shall be set if the non-3GPP access supports PMIPv6 and/or GTPv2. PMIP6_SUPPORTED flag is defined in IETF RFC 5779 [2]. The flag MIP6_INTEGRATED shall be set if DHCPv6 based Home Agent address discovery is supported as defined in IETF RFC 5447 [6]. The MIP4_SUPPORTED flag shall be set if the non-3GPP access supports MIPv4 FA-CoA mode.
Access Type	RAT-Type	M	This IE shall contain the non-3GPP access network technology type that is serving the UE. The TWAN shall set the Access Type value to "WLAN".
Access Network Identity	ANID	M	This IE shall contain the access network identifier used for key derivation at the HSS. (See 3GPP TS 24.302 [26] for all possible values)
Full Name for Network	Full-Network-Name	O	If present, this IE shall contain the full name for network as specified in 3GPP TS 24.302 [26]. This AVP may be inserted by the non-3GPP access network depending on its local policy and only when it is not connected to the UE’s Home Network. If the Visited Network Identifier is present, this AVP shall be set.
Short Name for Network	Short-Network-Name	O	If present, this IE shall contain the short name for network as specified in 3GPP TS 24.302 [26]. This AVP may be inserted by the non-3GPP access network depending on its local policy and only when it is not connected to the UE’s Home Network. If the Visited Network Identifier is present, this AVP shall be set.
Visited Network Identifier	Visited-Network-Identifier	O	If present, this IE shall contain the Identifier that allows the home network to identify the Visited Network. This AVP may be inserted by the non-3GPP access network depending on its local policy and only when it is not connected to the UE’s Home Network.
APN Id	Service-Selection	O	If present, this information element shall contain the Network Identifier part of the APN the user wants to connect to (if available).
Terminal Information	Terminal-Information	O	If present, this information element shall contain information about the user’s mobile equipment. The type of identity carried depends on the access technology type. For an HRPD access network, the 3GPP2‑MEID AVP shall be included in this grouped AVP.
Supported Features (See 3GPP TS 29.229 [24])	Supported-Features	O	If present, this information element shall contain the list of features supported by the origin host for the lifetime of the Diameter session.
Selected Trusted WLAN Identifier	WLAN-Identifier	O	If present, this IE shall contain the WLAN Identifier selected by the UE to access the Trusted WLAN Access Network (see clause 16 of 3GPP TS 23.402 [3]).
AAA Failure Indication	AAA-Failure-Indication	O	If present, this information element shall indicate that the request is sent after the non-3GPP access network has determined that a previously assigned 3GPP AAA Server is unavailable.
DER Flags	DER-Flags	O	This Information Element contains a bit mask. See 5.2.3.20 for the meaning of the bits.
Transport Access Type	Transport-Access-Type	C	For interworking with Fixed Broadband access networks (see 3GPP TS 23.139 [39]), if the access network needs to receive the IMSI of the UE in the authentication response, then this information element shall be present, and it shall contain the value "BBF" (see clause 5.2.3.19).
Supported TWAN Connection Modes	TWAN-Connection-Mode	O	The TWAN should include this IE. If present, this information element shall contain the TWAN connection modes supported by the TWAN, i.e. TSCM, SCM and/or MCM.
Provided Connectivity Parameters	TWAN-Connectivity-Parameters	C	This information element shall be present if the 3GPP AAA Server has previously authorized the SCM to be used for EPC access. TWAN-Connectivity-Parameters is a grouped AVP. If the requested connectivity has been granted, the following information elements shall be included: – selected APN – selected PDN type – UE IPv4 Address (for PDN type IPv4 or IPv4v6) – UE IPv6 Interface Identifier (for PDN type IPv6 or IPv4v6) – Protocol Configuration Options (if received from the PGW) – TWAG user plane MAC address The absence of both an IPv4 address and an IPv6 Interface Identifier indicates that the requested connectivity could not be granted. If the requested connectivity has not been granted, the following information elements may be included: – a cause indicating why the requested connectivity has not been granted – a Session Management back-off timer to be sent to the UE
TWAG Control Plane IP Address	TWAG-CP-Address	C	The TWAN shall include this IE if it indicates support of the MCM in the Supported TWAN Connection Modes IE. When present, this IE shall contain the TWAG Control Plane IPv4 Address, or the TWAG Control Plane IPv6 link local address, or both (if the TWAG supports IPv4 and IPv6), to be used for WLCP by the UE if the MCM is used.
IMEI Check in VPLMN Result	IMEI-Check-In-VPLMN-Result	C	The 3GPP AAA Proxy shall include this IE if it has performed an IMEI check in the VPLMN. When present, this IE shall contain the result of the IMEI check.
Domain-Specific Re-authentication Key Request	ERP-RK-Request	O	If present, this IE indicates the willingness of an ER server located in the non-3GPP access network to act as the ER server for this session. When present, this IE shall contain the name of the realm in which the ER server is located.

Table 5.1.2.1/2: Trusted non-3GPP Access Authentication and Authorization Answer

Information element name	Mapping to Diameter AVP	Cat.	Description
User Identity	User-Name	M	This information element shall contain the identity of the user. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15] and shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]. This IE shall include the leading digit used to differentiate between authentication schemes, if it contains a NAI other than an Emergency NAI for Limited Service State.
EAP payload	EAP payload	O	If present, this IE shall contain the Encapsulated EAP payload used for UE- 3GPP AAA Server mutual authentication. This IE shall not be included if the UE has been authenticated and the 3GPP AAA Server authorizes the SCM for EPC access for the UE and the Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH.
Authentication Request Type	Auth-Request-Type	M	It shall contain the value AUTHORIZE_AUTHENTICATE. See IETF RFC 4072 [5].
Result code	Result-Code / Experimental Result Code	M	This IE shall contain the result of the operation. Result codes are as in Diameter base protocol (see IETF RFC 6733 [58]). Experimental-Result AVP shall be used for STa errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP.
Session Alive Time	Session-Timeout	O	This AVP may be present if the Result-Code AVP is set to DIAMETER _SUCCESS; if present, it contains the maximum number of seconds the session is allowed to remain active.
Accounting Interim Interval	Accounting Interim-Interval	O	If present, this IE shall contain the Charging duration.
Pairwise Master Key	EAP-Master-Session-Key	C	This IE shall be present if Result-Code AVP is set to DIAMETER_SUCCESS.
Default APN	Context-Identifier	C	This AVP shall indicate the default APN for the user. If the Access Network Identity received in the Authentication and Authorization Request indicates WLAN (see clause 8.1.1.2 of 3GPP TS 24.302 [26]) and if the TSCM is selected, this AVP shall be set to the Default APN for Trusted WLAN if received from the HSS; otherwise this AVP shall be set to the subscriber’s Default APN for 3GPP and other non-3GPP accesses. It shall only be included if NBM is authorized for use, the non-3GPP access network was decided to be trusted, the Emergency-Indication bit of the Emergency-Services AVP is not set in the Authentication and Authorization Answer and the Result-Code AVP is set to either: – DIAMETER_SUCCESS or – DIAMETER_MULTI_ROUND_AUTH, and TWAN-S2a-Connectivity-Indicator is set in DEA-Flags. (see NOTE 1)
APN-OI replacement	APN-OI-Replacement	C	This AVP shall indicate the domain name to replace the APN-OI in the non-roaming case or in the home routed roaming case when constructing the PDN GW FQDN upon which a DNS resolution needs to be performed. See 3GPP TS 23.003 [3]. It shall only be included if NBM is authorized for use, the Emergency-Indication bit of the Emergency-Services AVP is not set in the Authentication and Authorization Answer and the Result-Code AVP is set to either: – DIAMETER_SUCCESS or – DIAMETER_MULTI_ROUND_AUTH, and TWAN-S2a-Connectivity-Indicator is set in DEA-Flags. (see NOTE 1)
APN and PGW Data	APN-Configuration	C	This information element shall only be sent if EPC Access is authorized, the Emergency-Indication bit of the Emergency-Services AVP is not set in the Authentication and Authorization Answer and the Result-Code AVP is set to either: – DIAMETER_SUCCESS or – DIAMETER_MULTI_ROUND_AUTH, and TWAN-S2a-Connectivity-Indicator is set in DEA-Flags. (see NOTE 1) When NBM is authorized for use, this AVP shall contain the default APN, the list of authorized APNs, including the wildcard APN if configured in the user’s subscription, user profile information and PDN GW information. When local IP address assignment is used (for HBM), this AVP shall only be present if DHCP based Home Agent discovery is used and contain the Home Agent Information for discovery purposes. The trusted non-3gpp access network knows if NBM is authorized for use or if a local IP address (for HBM) is assigned based on the flags in the MIP6-Feature-Vector. APN-Configuration is a grouped AVP, defined in 3GPP TS 29.272 [29]. When NBM is authorized for use, the following information elements per APN may be included: – APN – Authorized 3GPP QoS profile – Statically allocated User IP Address (IPv4 and/or IPv6) – Allowed PDN types – PDN GW identity – PDN GW allocation type – VPLMN Dynamic Address Allowed – APN-AMBR – Visited Network Identifier (see clause 5.1.2.1.4) – SIPTO permission When DSMIPv6 is used, the following information elements per Home Agent may be included: – HA-APN (Home Agent APN as defined in 3GPP TS 23.003 [14]) – Authorized 3GPP QoS profile – PDN GW identity When MIPv4 FACoA is used, the following information elements per APN may be included: – APN – Allowed PDN types
Serving GW Address	MIP6-Agent-Info	O	This AVP shall be used only in chained S2a-S8 cases and it shall be sent only if the Result-Code AVP is set to DIAMETER_SUCCESS.
Mobility Capabilities	MIP6-Feature-Vector	C	This information element shall only be sent if EPC Access is authorized and if the Result-Code AVP is set to either: – DIAMETER_SUCCESS or – DIAMETER_MULTI_ROUND_AUTH, and TWAN-S2a-Connectivity-Indicator is set in DEA-Flags. (see NOTE 1) It shall contain a AAA/HSS authorized set of mobility capabilities to the trusted non-3GPP access network, if dynamic mobility mode selection between NBM and HBM is done. It shall also be sent when authorizing access to EPC to a user accessing a TWAN. The PMIP6_SUPPORTED and/or the GTPv2_SUPPORTED shall be set to indicate that NBM (PMIPv6 or GTPv2) is authorized for use. Otherwise, ASSIGN_LOCAL_IP or MIP4_SUPPORTED flag shall be set by the 3GPP AAA Server to mandate which HBM mobility protocol is used. The MIP6_INTEGRATED flag shall be set if a Home Agent address is provided for DHCPv6 based Home Agent address discovery. In the latter case HA information for DHCPv6 discovery is provided via the APN-Configuration AVP.
Permanent User Identity	Mobile-Node-Identifier	C	This information element shall only be sent if the Result-Code AVP is set to either: – DIAMETER_SUCCESS or – DIAMETER_MULTI_ROUND_AUTH, and TWAN-S2a-Connectivity-Indicator is set in DEA-Flags. (see NOTE 1) This information element shall only be sent if NBM or MIPv4 is authorized for use, or when authorizing the user to access the TWAN without granting access to EPC S2a (i.e. non-seamless WLAN offload). If the user is authenticated, it shall contain an AAA/HSS assigned permanent user identity (i.e. an IMSI in root NAI format as defined in clause 19 of 3GPP TS 23.003 [14]) to be used: – by the MAG in subsequent PBUs as the MN-ID identifying the user in the EPS network, or – by the trusted non-3GPP access network in subsequent MIPv4 RRQs as the MN-NAI identifying the user in the EPS network, or – by the trusted non-3GPP access network to derive the IMSI to be sent in subsequent Create Session Request on GTP S2a. For an Emergency Attach, if the UE is UICC-less (i.e. the User Identity IE in the request contains an IMEI) or if the IMSI is not authenticated, the Permanent User Identity shall contain the IMEI in Emergency NAI for Limited Service State format as defined in clause 19 of 3GPP TS 23.003 [14]. This information element shall also be sent if HBM is authorized for use, or to access a Fixed Broadband access network without granting access to EPC S2a (i.e. non-seamless WLAN offload), and the Result-Code AVP is set to DIAMETER_SUCCESS and if the Transport Access Type in the request command indicated that the UE is accessing the EPC from a Fixed Broadband access network (i.e., the Transport-Access-Type AVP takes the value "BBF"); it shall contain an AAA/HSS assigned permanent user identity (i.e. an IMSI in root NAI format as defined in clause 19 of 3GPP TS 23.003 [14]) to be used: – by the trusted non-3GPP access network in subsequent PCC procedure for identifying the user in the EPS network. If this IE contains an identity based on IMSI, this IE shall not include the leading digit prepended in front of the IMSI used to differentiate between authentication schemes.
3GPP AAA Server URI	Redirect-Host	C	This information element shall be sent if the Result-Code value is set to DIAMETER_REDIRECT_INDICATION. When the user has previously been authenticated by another 3GPP AAA Server, it shall contain the Diameter URI of the 3GPP AAA Server currently serving the user. The node receiving this IE shall behave as defined in the Diameter base protocol (see IETF RFC 6733 [58]). The command shall contain zero or more occurrences of this information element. When choosing a destination for the redirected message from multiple Redirect-Host AVPs, the receiver shall send the Diameter request to the first 3GPP AAA Server in the ordered list received in the Diameter response. If no successful response to the Diameter request is received, the receiver shall send the Diameter request to the next 3GPP AAA Server in the ordered list. This procedure shall be repeated until a successful response is received from a 3GPP AAA Server.
UE Charging Data	3GPP-Charging-Characteristics	O	If present, this information element shall contain the type of charging method to be applied to the user (see 3GPP TS 29.061 [31]).
UE AMBR	AMBR	C	This Information Element shall contain the UE AMBR of the user. It shall be present only if the non-3GPP access network was decided to be trusted, the Result-Code AVP is set to DIAMETER_SUCCESS and ANID is "HRPD".
Trust Relationship Indicator	AN-Trusted	C	This AVP shall be included only in the first authentication and authorization response. If present, it shall contain the 3GPP AAA Server’s decision on handling the non-3GPP access network trusted or untrusted. For the STa case, the value "TRUSTED" shall be used.
Supported Features (See 3GPP TS 29.229 [24])	Supported-Features	O	If present, this information element shall contain the list of features supported by the origin host for the lifetime of the Diameter session.
FA-RK	MIP-FA-RK	C	This AVP shall be present if MIPv4 FACoA mode is used, the MN-FA authentication extension is supported and the Result-Code AVP is set to DIAMETER_SUCCESS.
FA-RK-SPI	MIP-FA-RK-SPI	C	This AVP shall be present if MIP-FA-RK is present
Trace information	Trace-Info	C	This information element shall only be sent if the Result-Code AVP is set to either: – DIAMETER_SUCCESS or – DIAMETER_MULTI_ROUND_AUTH, and TWAN-S2a-Connectivity-Indicator is set in DEA-Flags. (see NOTE 1) This AVP shall be included if the subscriber and equipment trace has been activated for the user in the HSS and signalling based activation is used to download the trace activation from the HSS to the non-3GPP access network. Only the Trace-Data AVP shall be included to the Trace-Info AVP and shall contain the following AVPs: – Trace-Reference – Trace-Depth-List – Trace-Event-List, for PGW – Trace-Collection-Entity The following AVPs may also be included in the Trace-Data AVP: – Trace-Interface-List, for PGW, if this AVP is not present, trace report generation is requested for all interfaces for PGW listed in 3GPP TS 32.422 [32] – Trace-NE-Type-List, with the only allowed value being "PDN GW". If this AVP is not included, trace activation in PDN GW is required.
MSISDN	Subscription-ID	C	This AVP shall contain the MSISDN of the UE and shall be sent if it is available and the non-3GPP access network is trusted and the Result-Code AVP is set to either: – DIAMETER_SUCCESS or – DIAMETER_MULTI_ROUND_AUTH, and TWAN-S2a-Connectivity-Indicator is set in DEA-Flags. (see NOTE 1)
DEA Flags	DEA-Flags	O	This Information Element contains a bit mask. See 5.2.3.21 for the meaning of the bits.
Selected TWAN Connection Mode	TWAN-Connection-Mode	C	The 3GPP AAA Server shall include this IE if it selects either the SCM or MCM and the Result-Code AVP is set to either: – DIAMETER_SUCCESS or – DIAMETER_MULTI_ROUND_AUTH, and TWAN-S2a-Connectivity-Indicator is set in DEA-Flags. (see NOTE 1) When present, this IE shall indicate the selected mode of operation (either SCM or MCM). If this IE is not present, the TWAN shall use TSCM.
Requested Connectivity Parameters	TWAN-Connectivity-Parameters	C	This IE shall contain the requested connectivity parameters received from the UE if the 3GPP AAA Server authorizes the SCM for TWAN and the Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH, and TWAN-S2a-Connectivity-Indicator is set in DEA-Flags. When present, the following information elements shall be included: – attach type (initial attach or handover) – requested APN (if received from the UE, see NOTE 3) if the UE did not request an Emergency Attach. – requested PDN type – Protocol Configuration Options (if received from the UE)
WLCP Key	WLCP-Key	C	This IE shall be present if the Result-Code AVP is set to DIAMETER_SUCCESS and the selected TWAN Connection Mode is MCM. If present, it shall contain the key for protecting WLCP signalling (see 3GPP TS 33.402 [19]).
Terminal Information	Terminal-Information	C	This information element enables to convey the user’s Mobile Equipment Identity to the non-3GPP access network in scenarios where the UE signals its Mobile Equipment Identity directly to the 3GPP AAA Server, i.e. when the Terminal-Information AVP is not received in the Authentication and Authorization Request. For a trusted WLAN access, the 3GPP AAA Server shall include this IE if the user’s Mobile Equipment Identity is available. When present, this grouped AVP shall contain the IMEI AVP and, if available, the Software Version AVP. (see NOTE 2)
Emergency Services	Emergency-Services	C	If the 3GPP AAA Server supports IMS emergency sessions over TWAN (see clause 4.5.7 of 3GPP TS 23.402 [3]), it shall include this IE and set the Emergency-Indication bit when the UE indicates an Emergency Attach in EAP-AKA’ signalling.
Emergency Info	Emergency-Info	C	When present, this IE shall contain the identity of the PDN GW dynamically allocated for emergency services. It shall be present for a non-roaming authenticated user, if this information was received from the HSS, the TWAN indicated support of IMS Emergency sessions and the Result-Code AVP is set to either: – DIAMETER_SUCCESS or – DIAMETER_MULTI_ROUND_AUTH and TWAN-S2a-Connectivity-Indicator is set in DEA-Flags. (see NOTE 1)
ERP Keying Material	Key	C	If the 3GPP AAA Server supports ERP, this IE shall be present if the Result-Code AVP is set to DIAMETER_SUCCESS, the domain-specific re-authentication key was requested and the use of ERP is authorized for this user (see clause 8.2.3.27). In that case, this IE shall contain the Domain-Specific Root Key (DSRK) and the Extended Master Session Key name (EMSKname), and it may contain the DSRK lifetime.
ERP Realm	ERP-Realm	C	This IE shall be present if the ERP Keying Material is present. This IE indicates the realm where the ER server is located; it also indicates the domain name to use as the realm part of the KeyName-NAI used during ERP-based re-authentication.
UE Usage Type	UE-Usage-Type	C	This IE shall be present if this information is available in the user subscription. When present, this IE shall contain the UE Usage Type of the subscriber.
NOTE 1: The 3GPP AAA Server may decide to not include the AVP if the Result-Code AVP is set to DIAMETER_SUCESS and the AVP has already been sent in a previous message with the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH and the TWAN-S2a-Connectivity-Indicator set in DEA-Flags. In that case, the TWAN shall consider the information received in the previous message as still applicable. NOTE 2: For a trusted WLAN access, the UE signals its Mobile Equipment Identity to the 3GPP AAA Server via EAP-AKA’ and the 3GPP AAA Server forwards this information to the TWAN in the Terminal-Information AVP in the Authentication and Authorization Answer. NOTE 3: The Service-Selection AVP in the Requested Connectivity Parameters IE shall contain the APN requested by the UE, regardless of whether this APN is authorized by a matching APN or by the wildcard APN in the user’s subscription.

5.1.2.1.2 3GPP AAA Server Detailed Behaviour

On receipt of the first DER message, the 3GPP AAA Server shall check the validity of the ANID AVP and whether the non-3GPP access network is entitled to use the included value. The correct syntax of the ANID is checked as follows:

– In a non-roaming case, i.e. when the 3GPP AAA Server receives the request directly and not via the 3GPP AAA Proxy, checking ANID is mandatory;

– In a roaming case when the request is received via an 3GPP AAA proxy, checking ANID is optional. The 3GPP AAA Server may decide to check ANID based on local configuration, e.g. depending on the received visited network identifier.

– If the checking result shows that the included ANID value is not valid (not defined by 3GPP) or that the requesting entity is not entitled to use the received ANID value, the Result-Code shall be set to DIAMETER_UNABLE_TO_COMPLY.

The 3GPP AAA Server shall check if user data exists in the 3GPP AAA Server (containing valid authentication information for the current access network identity). If not, the 3GPP AAA Server shall use the procedures defined in SWx interface to obtain access authentication and authorization data.

If IMEI check is required by operator policy and the TWAN is in the HPLMN, the 3GPP AAA Server shall:

– retrieve the IMEI(SV) from the UE as specified in 3GPP TS 23.402 [26];

– if the IMEI(SV) is available, check the Mobile Equipment’s identity status towards the EIR, using the ME Identity Check procedure (see clause 11);

– upon getting the IMEI check result from the EIR, determine whether to continue or stop the authentication and authorization procedure;

– if the IMEI(SV) is not available, determine whether to continue or stop the authentication and authorization procedure based on operator policy;

– if the 3GPP AAA Server determines that the authentication and authorization procedure shall be stopped, it shall:

– notify the UE that the Mobile Equipment used is not acceptable to the network (e.g. the Mobile Equipment is on the prohibited list of the EIR), as specified in 3GPP TS 24.302 [26];

– respond to the TWAN with the Experimental-Result-Code DIAMETER_ERROR_ILLEGAL_EQUIPMENT.

Specific operator policies may be configured for emergency services, regarding whether to check the IMEI and, if the IMEI needs to be checked, whether to continue or stop the authentication and authorization procedure upon getting the IMEI check result or when the IMEI(SV) is not available.

If the IMEI-Check-Required-In-VPLMN bit is set in the DER-Flags AVP of the first Authentication and Authorization Request message and the TWAN is in the VPLMN, the 3GPP AAA Server shall:

– retrieve the IMEI(SV) from the UE as specified in 3GPP TS 23.402 [26];

– request the VPLMN to check the IMEI, by setting the IMEI-Check-Request-In-VPLMN bit in the DEA-Flags AVP and including the IMEI(SV) if available in the DEA message;

– upon getting the IMEI-Check-In-VPLMN-Result AVP in the subsequent DER message, if the IMEI check failed in the VPLMN:

– notify the UE that the Mobile Equipment used is not acceptable to the network (e.g. the Mobile Equipment is on the prohibited list of the EIR), as specified in 3GPP TS 24.302 [26];

– respond to the TWAN with the Experimental-Result-Code DIAMETER_ERROR_ILLEGAL_EQUIPMENT.

See Annex A.2.3 and A.3.2.

If the 3GPP AAA Server receives a request message not related to any existing session and is able to recognize that the non-3GPP access network included the AAA-Failure-Indication AVP in the request, the 3GPP AAA Server shall also include the AAA-Failure-Indication AVP over the SWx interface, while retrieving the access authentication and authorization data from the HSS.

If SWx authentication response indicates that:

– The user does not exist, then the 3GPP AAA Server shall respond the non-3GPP access network with Experimental-Result-Code DIAMETER_ERROR_USER_UNKNOWN.

– The user does not have non-3GPP access subscription, then 3GPP AAA Server shall respond the non-3GPP access network with Experimental-Result-Code DIAMETER_ERROR_USER_NO_NON_3GPP_SUBSCRIPTION.

– The user is not allowed to roam in the visited network, then 3GPP AAA Server shall respond the non-3GPP access network with Experimental-Result-Code DIAMETER_ERROR_ROAMING_NOT_ALLOWED.

– The user is currently being served by a different 3GPP AAA Server, then the 3GPP AAA Server shall respond to the non-3GPP access network with the Result-Code set to DIAMETER_REDIRECT_INDICATION and the Redirect-Host set to the Diameter URI of the 3GPP AAA Server currently serving the user (this Diameter URI shall be constructed based on the Diameter Identity included in the 3GPP-AAA-Server-Name AVP returned in the SWx authentication response from the HSS).

– The user is not allowed to use the current access type, then the 3GPP AAA Server shall respond to the non-3GPP access network with Experimental-Result-Code DIAMETER_ERROR_RAT_TYPE_NOT_ALLOWED.

– Any other error occurred, then the error code DIAMETER_UNABLE_TO_COMPLY shall be returned to the non-3GPP access network.

When SWx authentication response includes the requested authentication information, the 3GPP AAA Server shall proceed with the authentication and authorization procedure. The 3GPP AAA Server shall use the procedures defined in SWx interface to obtain the user’s subscription profile from HSS.

Before sending out the authentication challenge, the 3GPP AAA Server shall decide, whether the access network is handled as Trusted or Untrusted. The 3GPP AAA Server shall make the decision based on the Access Network Identifier and Visited Network Identity information elements, according to its local policies. The local policies of the 3GPP AAA Server shall be based on the security criteria described in 3GPP TS 33.402 [19].

NOTE 1: The network operator can configure this e.g. according to the roaming agreements with the non-3GPP AN operator or with VPLMN operator.

In a roaming case, if the 3GPP AAA Server has received the trust relationship indicator from the VPLMN (AN-Trusted AVP), the 3GPP AAA Server may use this information as input parameter to the trusted/untrusted evaluation.

The VPLMN trust relationship indicator may be utilized only if the appropriate trust relationship exists between the HPLMN and VPLMN operators.

Based on the trusted/untrusted decision, the 3GPP AAA Server may send a trust relationship indication to the UE, as described in 3GPP TS 24.302 [26].

The 3GPP AAA Server shall indicate the trust relationship assessment of the non-3GPP access network to the UE in the AT_TRUST_IND attribute (in the EAP-Request/AKA’-Challenge) as defined in 3GPP TS 24.302 [26]. The 3GPP AAA Server shall also indicate the trust relationship assessment to the non-3GPP access network using AN-Trusted AVP in the DEA command.

If the decision is "Trusted", the STa authentication and authorization procedure is executed as described here, in clause 5.1.2.1 and it clauses. Otherwise, the SWa authentication and authorization procedure is executed as described in clause 4.1.2.1.

The 3GPP AAA Server marks the trust relationship as "trusted" with the User Identity. If the 3GPP AAA Server detects that an S6b session already exists for the corresponding UE and the S6b session was established as a result of an authentication request for DSMIPv6, the 3GPP AAA Server shall send the trust relationship to the PDN GW as specified in clause 9.1.2.5.

The 3GPP AAA Server shall run EAP-AKA’ authentication as specified in 3GPP TS 33.402 [19]. Exceptions shall be treated as error situations and the result code shall be set to DIAMETER_UNABLE_TO_COMPLY.

Once authentication is successfully completed, the 3GPP AAA Server shall perform the following authorization checking (if there is an error in any of the steps, the 3GPP AAA Server shall stop processing and return the corresponding error):

1) Check if the user is barred to use the non 3GPP Access. If it is so, then the Result-Code shall be set to DIAMETER_AUTHORIZATION_REJECTED

2) Check the access type. If the received access type is listed in the user’s disallowed RAT-Types,

this shall be treated as error and the Experimental-Result-Code DIAMETER_ERROR_RAT_TYPE_NOT_ALLOWED shall be returned.

The following steps are only executed if the non-3GPP access network was decided to be Trusted.

3) If the APN Id IE is present in the request, check if the user has a subscription for the requested APN or for the wildcard APN. If not, Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_NO_APN_SUBSCRIPTION

4) for a trusted WLAN access (i.e. ANID in the request indicates WLAN, see clause 8.1.1.2 of 3GPP TS 24.302 [26]), check if the user is authorized to access to EPC via S2a and/or non-seamless WLAN offload via the selected WLAN:

– if no TWAN-Access-Info AVP was received from the HSS in the user’s subscription, the 3GPP AAA Server shall consider that access to EPC and non-seamless WLAN Offload is authorized;

– if one or more TWAN-Access-Info AVP(s) was received from the HSS in the user’s subscription:

– if the TWAN has signalled the selected Trusted WLAN in the request and the selected Trusted WLAN identifier contains only the SSID of the selected WLAN, the 3GPP AAA Server shall authorize the access methods allowed by the TWAN-Access-Info AVP explicitly matching the selected trusted WLAN (i.e. including a WLAN-Identifier AVP with the same SSID and without HESSID information) if any;

NOTE 2: When the TWAN does not include the HESSID in the request, the authorization information in the 3GPP AAA Server containing both SSID and HESSID is not applicable; therefore, in order to get specific authorization of the UE in this case, the operator needs to define authorization information for the SSID in question (without HESSID), or to rely on the "wildcard" authorization (i.e., a TWAN-Access-Info AVP not including a WLAN-Identifier AVP).

– if the TWAN has signalled the selected Trusted WLAN in the request and the selected Trusted WLAN identifier contains both the SSID and the HESSID of the selected WLAN, the 3GPP AAA Server shall authorize the access methods allowed by the TWAN-Access-Info AVP explicitly matching the selected trusted WLAN (i.e. including a WLAN-Identifier AVP with the same SSID and same HESSID);

Else, if no match is found, the 3GPP AAA Server shall authorize the access methods allowed by the TWAN-Access-Info AVP explicitly matching the HESSID of the selected Trusted WLAN identifier (i.e. TWAN-Access-Info including a WLAN-Identifier AVP with the same HESSID and without SSID information);

Else, if no match is found, the 3GPP AAA Server shall authorize the access methods allowed by the TWAN-Access-Info AVP explicitly matching the SSID of the selected Trusted WLAN identifier (i.e. TWAN-Access-Info including a WLAN-Identifier AVP with the same SSID and without HESSID information) ;

– otherwise, if the selected Trusted WLAN does not match explicitly any of the TWAN-Access-Info or if TWAN has not signalled the selected Trusted WLAN Identifier, the 3GPP AAA Server shall apply the access methods allowed by the "wildcard" TWAN-Access-Info AVP (i.e. TWAN-Access-Info AVP not including a WLAN-Identifier AVP) if any;

– otherwise, if the "wildcard" TWAN-Access-Info is not present, the 3GPP AAA Server shall consider that access to EPC and non-seamless WLAN Offload is not authorized.

5) Check if the user is not authorized to perform non-seamless WLAN Offload and, if the user is also barred from using the subscribed APNs, then the Result-Code shall be set to DIAMETER_AUTHORIZATION_REJECTED.

6) If present, check the flags of the received MIP6-Feature-Vector AVP:

– If the MIP6-INTEGRATED flag is set and the 3GPP AAA Server has authorized DHCP Home Agent assignment, the 3GPP AAA Server shall include the Home Agent addresses in the APN-Configuration AVP in the response and the MIP6-Feature-Vector AVP with the MIP6-INTEGRATED flag set. If the HA assignment via DHCPv6 is not used, the MIP6-Feature-Vector AVP with the MIP6-INTEGRATED flag not set shall be sent.

– The PMIP6_SUPPORTED and/or GTPv2 SUPPORTED flag indicates to the 3GPP AAA Server whether the trusted non-3GPP access network supports NBM or not.

As specified in 3GPP TS 23.402 [3], based on the information it has regarding the UE (see 3GPP TS 24.302 [26]), local/home network capabilities and local/home network policies, the 3GPP AAA Server may perform mobility mode selection between NBM and HBM.
For a trusted WLAN access, if the user is successfully authenticated and authorized for this access, the 3GPP AAA Server may either only authorize the user to access to EPC via S2a (i.e. EPC-routed service only), or only authorize the user to access the TWAN without granting access to EPC via S2a (i.e. non-seamless WLAN offload service only), or authorize both EPC-routed and non-seamless WLAN offload services, taking also into account the subscriber profile, access network, the selected WLAN identifier if present, and the TWAN’s non-seamless WLAN offload capability if present, and the authorized mode of operation (TSCM, SCM or MCM). The 3GPP AAA Server may authorize both EPC-routed and non-seamless WLAN offload services only if the MCM is selected, or in non-roaming scenarios if the TSCM is selected; the 3GPP AAA Server shall not authorize both EPC-routed and non-seamless WLAN offload services if the SCM is selected or in roaming scenarios if the TSCM is selected.

If the 3GPP AAA Server decides that access to EPC is authorized and NBM should be used for such access, the PMIP6_SUPPORTED and GTPv2_SUPPORTED flags shall be set in the response to indicate that NBM is authorized for use for the UE by the trusted non 3GPP access network. If only the PMIPv6_SUPPORTED or the GTPv2_SUPPORTED flag is present in the response, the trusted non-3GPP access network shall assume that this also indicates that NBM is authorized for use. In addition, for a trusted WLAN access, the Non-seamlesss WLAN offload Authorization flag shall be set in the DEA-Flags AVP in the response if the non-seamless WLAN offload is authorized.

If the 3GPP AAA Server decides to only authorize the user to access the TWAN without granting access to EPC S2a (i.e. non-seamless WLAN offload service only), none of the flags (PMIP6_SUPPORTED, GTPv2_SUPPORTED, MIP4_SUPPORTED, MIP6-INTEGRATED, ASSIGN_LOCAL_IP) shall be set in the response, i.e. the Mobility Capabilities IE is not sent in the response, and the Non-seamlesss WLAN offload Authorization flag shall be set in the DEA-Flags AVP in the response.

If the 3GPP AAA Server decides that a local IP address should be assigned for HBM, the ASSIGN_LOCAL_IP flag shall be set in the response to indicate to the trusted non 3GPP access network that a local IP address (for HBM) should be assigned.

The 3GPP AAA Server shall not set the PMIP6_SUPPORTED/GTPv2_SUPPORTED and ASSIGN_LOCAL_IP flags both at the same time in the response.

– The MIP4_SUPPORTED flag indicates to the 3GPP AAA Server whether the trusted non-3GPP access network supports MIPv4 FA-CoA mode or not. As specified in 3GPP TS 23.402 [3], based on the information it has regarding the UE (see 3GPP TS 24.302 [26]), local/home network capabilities and local/home network policies, the 3GPP AAA Server may perform mobility mode selection. If the 3GPP AAA Server decides that MIPv4 FA-CoA mode should be used, the MIP4_SUPPORTED flag shall be set in the response.

NOTE 3: When selecting DSMIPv6 the AAA server assumes that the trusted non 3GPP access gateway has the capability to assign a local IP address to the UE.

For Trusted WLAN access, the 3GPP AAA Server shall select the TWAN connection mode, i.e. either TSCM, SCM or MCM, taking into account the modes supported by the TWAN (as reported in the first DER message), those supported by the UE (as reported in the EAP payload, see 3GPP TS 24.302 [26]) and operator policy. The 3GPP AAA Server shall then indicate to the TWAN the TWAN connection mode it has selected, either explicitly using the Selected TWAN Connection Mode IE if it has selected SCM or MCM, or implicitly by not including the Selected TWAN Connection Mode IE if it has selected TSCM.

For Trusted WLAN access, if the 3GPP AAA Server has determined that the EAP-AKA’ authentication is correct (i.e., the UE has sent a valid EAP-AKA’ challenge response) and if the 3GPP AAA Server authorizes the SCM to be used for EPC access, the 3GPP AAA Server shall reply to the first DER message it receives with a result code set to DIAMETER_MULTI_ROUND_AUTH, leave the EAP-Payload AVP absent in the reply, and set the TWAN-S2a-Connectivity-Indicator bit to 1 in the DEA-Flags AVP; it shall also include in the response command all subscription-related parameters for the user, so the TWAN is able to proceed with the setup of the required S2a network connectivity (e.g., establishment of the GTP tunnel). After receiving a subsequent DER command from the TWAN, the 3GPP AAA Server shall check if the TWAN-S2a-Connectivity-Indicator is set, and if so, it may disregard the received EAP-Payload, since the EAP-AKA’ challenge response has been already successfully checked. If the TWAN could not provide the requested S2a network connectivity and included a Session Management back-off timer in the DER command, the 3GPP AAA Server shall instruct the UE to not request new PDN connectivity to the same APN for the indicated time as specified in 3GPP TS 24.302 [26]. See Annex A.

Once the Authentication and Authorization procedure successfully finishes, the 3GPP AAA Server shall download, the authentication data, the list of authorized APN’s if the UE did not indicate an Emergency Attach in EAP-AKA’ signalling (see 3GPP TS 24.302 [26]), and the authorized mobility protocols in the authentication and authorization response from the HSS (see SWx procedure in Clause 8.1.2.1). If the Access Network Identity received in the Authentication and Authorization Request indicates WLAN (see clause 8.1.1.2 of 3GPP TS 24.302 [26]) and if the TSCM is selected, the 3GPP AAA Server shall set the Default APN in the Authentication and Authorization Answer to the Default APN for Trusted WLAN if received from the HSS, otherwise to the subscriber’s Default APN for 3GPP and other non-3GPP accesses.

For a trusted WLAN access, if the user is authorized to access to EPC via S2a, and/or non-seamless WLAN offload via the selected WLAN, the 3GPP AAA Server shall send the user’s Mobile Equipment Identity to the TWAN, if this information is available.

Once the Authentication and Authorization procedures successfully finish and if MIPv4 FACoA mode is used the 3GPP AAA Server shall calculate the MIPv4 FACoA mobility security parameters as defined in 3GPP TS 33.402 [19] and include these in the authentication and authorization response to the trusted non 3GPP access network.

Exceptions to the cases specified here shall be treated by 3GPP AAA Server as error situations, the Result-Code shall be set to DIAMETER_UNABLE_TO_COMPLY and, therefore, no authorization information shall be returned.

For Fixed Broadband access network, the 3GPP AAA Server shall determine if the UE is connected via a BBF-defined WLAN access according to the Transport-Access-type AVP. If the UE is connected via a BBF-defined WLAN access, the 3GPP AAA Server shall perform the enabling of the UE reflective QoS function as specified in 3GPP TS 24.139 [43].

NOTE 4: This behaviour is applicable for both fixed broadband access interworking and the fixed broadband access convergence. The architecture of fixed broadband access interworking is specified in 3GPP TS 23.139 [39]. The architecture of the fixed broadband access convergence is specified in 3GPP TS 23.203 [45].

If the 3GPP AAA Server supports IMS Emergency sessions over WLAN (see clause 4.5.7.2 of 3GPP TS 23.402 [3]), the 3GPP AAA Server shall proceed as specified above, but with the following modifications, for an Emergency Attach:

1) The 3GPP AAA Server shall reject the Authentication and Authorization Request and set the result code to DIAMETER_UNABLE_TO_COMPLY if the TWAN does not indicate support of IMS Emergency sessions in the DER-Flags AVP in the request.

2) If the UE does not have an IMSI:

– if local policies allow emergency sessions for all UEs, the 3GPP AAA Server shall skip the procedures defined for the SWx interface to obtain access authentication and authorization data, shall skip the authorization checkings and shall authorize the UE to access to EPC for emergency services. The Permanent User Identity IE in the answer shall contain the IMEI in Emergency NAI for Limited Service State format as defined in clause 19 of 3GPP TS 23.003 [14];

– otherwise the 3GPP AAA Server shall reject the request with the Experimental-Result-Code set to DIAMETER_ERROR_USER_UNKNOWN.

3) If the UE has an IMSI but the IMSI is not authenticated:

– if local policies allow emergency sessions for unauthenticated UEs with an IMSI, the 3GPP AAA Server shall skip the procedures defined for the SWx interface to obtain access authorization data, shall skip the authorization checkings, shall request the UE to provide its IMEI as specified in clause 13.4 of 3GPP TS 33.402 [19] and shall authorize the UE to access to EPC for emergency services. The Permanent User Identity IE in the answer shall contain the IMEI in Emergency NAI for Limited Service State format as defined in clause 19 of 3GPP TS 23.003 [14];

– otherwise the 3GPP AAA Server shall reject the request with the Experimental-Result-Code set as specified for authentication failures in this clause.

4) If the UE has an authenticated IMSI but the UE is not authorized to access the EPC:

– if local policies allow emergency sessions for any authenticated UE, the 3GPP AAA Server shall authorize the UE to access to EPC for emergency services;

– otherwise the 3GPP AAA Server shall reject the request with the Experimental-Result-Code set as specified for authorization failures in this clause.

5) When authorizing a UE to access to EPC for emergency services, the 3GPP AAA Server:

– shall set the Emergency-Indication bit of the Emergency-Services IE in the answer;

– shall not allow the use of non-seamless WLAN offload services.

In addition, if the 3GPP AAA Server supports IMS Emergency sessions over WLAN (see clause 4.5.7.2 of 3GPP TS 23.402 [3]), the 3GPP AAA Server shall also include the Emergency Info IE in the Authentication and Authorization Answer, for emergency and non-emergency Attach, if this information was received from the HSS, the user is not roaming, the TWAN indicated support of IMS Emergency sessions and the Result-Code AVP is set to either:

– DIAMETER_SUCCESS or

– DIAMETER_MULTI_ROUND_AUTH and TWAN-S2a-Connectivity-Indicator is set in DEA-Flags.

Once the Authentication and Authorization procedures successfully finish, if a domain-specific re-authentication key was requested and the use of ERP is authorized for this user based on subscription parameter, the 3GPP AAA Server which support ERP shall derive the DSRK from the EMSK and the domain name received in the request as specified in IETF RFC 6696[55] and shall include the DSRK, the EMSKname, and optionally the DSRK lifetime in the authentication and authorization response to the non-3GPP access network.

Otherwise, when the 3GPP AAA Server does not support ERP, the domain-specific re-authentication key request is ignored if present in the authentication and authorization request.

5.1.2.1.3 3GPP AAA Proxy Detailed Behaviour

The 3GPP AAA Proxy is required to handle roaming cases in which the non-3GPP access network is connected to a VPLMN. The 3GPP AAA Proxy shall act as a stateful proxy, with the following additions.

If IMEI check is required by operator policy and the TWAN is in the VPLMN, the 3GPP AAA Proxy shall:

– set the IMEI-Check-Required-In-VPLMN bit in the first Authentication and Authorization Request message sent to the 3GPP AAA Server;

– upon receipt of a subsequent DER message with the IMEI-Check-Request-in-VPLMN bit set to 1 in the DER-Flags AVP,

– if the IMEI(SV) is available, check the Mobile Equipment’s identity status towards the EIR, using the ME Identity Check procedure (see clause 11);

– upon getting the IMEI check result from the EIR, determine whether to continue or stop the authentication and authorization procedure;

– if the IMEI(SV) is not available, determine whether to continue or stop the authentication and authorization procedure based on operator policy;

– send the result of the IMEI check to the 3GPP Server in the IMEI-Check-In- VPLMN-Result AVP.

See Annex A.2.3 and A.3.2.

On receipt of an authentication and authorization request, the 3GPP AAA Proxy

– shall check the Visited-Network-Identifier AVP,

– If the AVP is not present, the 3GPP AAA Proxy shall insert it before forwarding the request to the 3GPP AAA Server.

– If the AVP is present, the 3GPP AAA Proxy may check and overwrite its value, depending on its local policy, e.g. the trusted non-3GPP access network is being operated by the VPLMN operator or by a third party.

– shall check the ANID AVP. If the result of the checking shows that the included ANID value is not valid (not defined by 3GPP) or that the requesting entity is not entitled to use the received value, the Result-Code shall be set to DIAMETER_UNABLE_TO_COMPLY and the authentication response shall be sent to the trusted non-3GPP access network.

– may take a decision about the trustworthiness of the non-3GPP access from VPLMN’s point of view. If such decision is taken, it shall be based on the Access Network Identifier and optionally, on further information about the non-3GPP access network, according to the 3GPP AAA Proxy’s local policies. These local policies shall reflect the security criteria described in 3GPP TS 33.402 [19], with the assumption that the PDN GW will be allocated in the VPLMN.

NOTE 1: For example, if hop-by-hop security relationship exists between the NAS and the 3GPP AAA Proxy, the 3GPP AAA Proxy may use the Origin-Host AVP to uniquely identify the NAS and the access network.

The decision about the trustworthiness of the non-3GPP access network is encoded to the VPLMN trust relationship indicator that is inserted to the authentication and authorization request.

On receipt of the first authentication and authorization request, the 3GPP AAA Proxy shall check locally configured information whether users from the HPLMN are allowed to activate a PDN connection from the non-3GPP access network via this (V)PLMN. If not, the Experimental-Result-Code shall be set to DIAMETER_ERROR_ROAMING_NOT_ALLOWED and the authentication and authorization response shall be sent to the non-3GPP access network.

NOTE 2: It is assumed that there is a roaming agreement between the non-3GPP access network and the VPLMN.

On receipt of the first authentication and authorization request, a 3GPP AAA Proxy which supports ERP may check whether ERP is supported by the non-3GPP access network. If the non-3GPP access network supports ERP and there is an ER server requesting a domain-specific re-authentication key in the authentication and authorization request, the 3GPP AAA Proxy may not authorize it based on locally configured information, remove the domain-specific key request before forwarding the request. If the non-3GPP access network supports ERP and there is no ER server in the non-3GPP access network or if the ER server in the non-3GPP access network was not authorized based on locally configured information, the 3GPP AAA Proxy may act as ER server and include the domain-specific re-authentication key request into the first authentication and authorization request forwarded to the 3GPP AAA server.

On receipt of the authentication and authorization answer that completes a successful authentication, the 3GPP AAA Proxy

– may check locally configured information about using the chained S8-S2a option towards the given HPLMN. If chaining is required, the 3GPP AAA Proxy shall select a Serving GW from its network configuration database and shall include the Serving GW address in the answer.

– shall check locally configured information for the maximum allowed static QoS parameters valid for visitors from the given HPLMN and modify the QoS parameters received from the 3GPP AAA Server, to enforce the policy limitations.

– shall record the state of the connection (i.e. Authentication and Authorization Successful).

– may check if ERP keying material is provided in the answer in response to the domain-specific re-authentication key requested by the 3GPP AAA Proxy acting as an ER server. If it is, the 3GPP AAA Proxy shall remove the ERP keying material from the answer forwarded to the non-3GPP access network and store the DSRK, the EMSKname and the DSRK lifetime. If there is no ERP keying material and the DEA-Flag does not indicate that ERP is supported by the 3GPP AAA Server, the 3GPP AAA Proxy shall not forward any ERP related messages to the 3GPP AAA Server.

– shall forward the ERP keying material to the TWAN if received from the 3GPP AAA Server and the ER server is located in the TWAN.

5.1.2.1.4 Trusted non-3GPP access network Detailed Behaviour

The Trusted non-3GPP access network shall initiate the Trusted non-3GPP Access Authentication and Authorization procedure when the user attaches to the access network. During the authentication, it shall act as a pass-through EAP authenticator.

If the IMEI-Check-Request-In-VPLMN bit is set in the DEA-Flags AVP of the DEA message, the TWAN shall request the 3GPP AAA Proxy to check the IMEI, by setting the IMEI-Check-Request-In-VPLMN bit in the DER-Flags AVP and including the IMEI(SV) in the DER message. See Annex A.2.3 and A.3.2.

If PMIPv6, GTPv2 or MIPv4 FACoA is used, at successful completion of the procedure, the trusted non-3GPP access network shall store the non-3GPP user data received from the 3GPP AAA Server. The trusted non-3GPP access network shall utilize these data

– To authorize the APNs received in PDN connection creation request from the UE;

– To authorize the requested home address types: IPv4 home address and/or IPv6 home network prefix;

– To check if the UE requested APN is authorized as such or based on the wildcard APN.

NOTE: The user will be allowed to create PDN connections only to the subscribed APNs and use the address types that are allowed by the subscribed PDN types.

If DSMIPv6 is used and if the trusted non-3GPP access network has received the PGW identity in form of the FQDN from the 3GPP AAA Server, then the trusted non-3GPP access network may obtain the IP address of the Home Agent functionality of that PGW as described in 3GPP TS 29.303 [34].

If MIPv4 FACoA is used and if the non-3GPP access network has received FA-RK-SPI and FA-RK from the 3GPP AAA Server , the trusted non-3GPPaccess network will use FA-RK key and FA-RK-SPI to further derive MN-FA shared key and MN-FA-SPI, as defined in 3GPP TS 33.402 [19]. These are used to process the MN-FA Authentication Extension in the RRQ/RRP messages if the extension is present.

If the subscriber is not roaming and the SIPTO-Permission information for an APN is present, the HSGW shall allow SIPTO for that APN only if the SIPTO-Permission information indicates so. If the subscriber is not roaming and the SIPTO-Permission information for an APN is not present, the HSGW may allow SIPTO for that APN. If the subscriber is roaming and the SIPTO-Permission information for an APN is present, the HSGW shall allow SIPTO for that APN only if the SIPTO-Permission information indicates so and the VPLMN Dynamic Address is allowed and the HSGW selects a PDN GW in the VPLMN. For the requested APN allowed for SIPTO, the trusted non-3GPP access network may use the 3GPP DNS mechanism to select a PGW which is close to the HSGW. Detailed behaviour is specified in 3GPP2 X.S0057 [25], 3GPP TS 23.402 [3] and 3GPP TS 29.303 [34].

For optimized handover of an emergency session from E-UTRAN to an S2a based cdma2000^® HRPD access network, if the trusted non-3GPP access network supports Emergency services for users in limited service state, then the trusted non-3GPP access network shall skip the authentication procedure (for users without an IMSI or with an IMSI marked as unauthenticated); or if the trusted non-3GPP access network accepts that the authentication may fail (for users with an IMSI), it shall continue with the procedure. For these cases, the Trusted non-3GPP access network shall release any non-emergency PDN connections.

The TWAN decides the S2a protocol variant to use if access to EPC is authorized and the TWAN decides to establish S2a. The TWAN may be configured with the S2a protocol variant(s) on a per PLMN granularity, or may retrieve information regarding the S2a protocol variants supported by the PDN GW (PMIPv6 or/and GTPv2) from the Domain Name Service Function as described in 3GPP TS 29.303[34]. For static PDN GW assignment, in order to determine the PLMN of the PDN GW, the TWAN may use the Visited Network Identifier, if received from the 3GPP AAA Server, or the FQDN of the PDN GW, if included in the MIP6-Agent-Info AVP of the APN in use; if none of them are available, it may use the PLMN where the 3GPP AAA Server is located. If the TWAN supports Dedicated Core Networks and receives the UE-Usage-Type from the 3GPP AAA Server, the TWAN shall select the PGW as specified in clause 5.8 of 3GPP TS 29.303 [34].

For Trusted WLAN access, the TWAN should attempt the establishment of the S2a connectivity if the 3GPP AAA Server authorizes the SCM to be used for EPC access and the 3GPP AAA Server answers the authentication request with a result code of DIAMETER_MULTI_ROUND_AUTH and with the TWAN-S2a-Connectivity-Indicator bit set to 1 in the DEA-Flags AVP. After completing the S2a network connectivity actions, the TWAN shall re-issue a new DER command including the last EAP-Payload sent in a former request, and setting the TWAN-S2a-Connectivity-Indicator bit to 1 in the DER-Flags AVP. If the requested connectivity has been granted, the TWAN shall also provide the 3GPP AAA Server with the connectivity parameters provided to the UE; otherwise, the TWAN should also provide a cause indicating why the requested connectivity could not be granted and may provide a Session Management back-off timer to be sent to the UE to instruct the UE to not request new PDN connectivity to the same APN for the indicated time.

If the Trusted non-3GPP access networkdetermines that a previously assigned 3GPP AAA Sever is unavailable, it may attempt to send a new authentication and authorization request to an alternate 3GPP AAA Server. If the Trusted non-3GPP access network receives from this new server a redirect indication towards the former server (due to the HSS having stored the former 3GPP AAA Server identity), it shall terminate all previously existing sessions and PDN connections for that user, and it shall re-send again the request towards the new server, but it shall include the AAA-Failure-Indication AVP in the new request.

If the TWAN supports IMS Emergency sessions over WLAN (see clause 4.5.7.2 of 3GPP TS 23.402 [3]), the TWAN shall:

– set the Emergency-Capability-Indication bit in the DER-Flags AVP to indicate support of IMS emergency sessions to the 3GPP AAA Server (to be forwarded to the UE via EAP-AKA’ signalling).

– interpret the receipt of an Emergency NAI for Limited Service State or an IMSI-based Emergency NAI from the UE, or the Emergency-Services AVP from the 3GPP AAA Server, with the Emergency-Indication bit set, as an indication that the UE requests to access the EPC for emergency services;

– give preferential treatment to UEs which access the EPC for emergency services, e.g. in scenarios including network overload;

– use its Emergency Configuration Data to determine the APN to be associated with the emergency PDN connection and possibly the PGW to use;

– use the PGW identified in the Emergency PGW Identity IE, during a handover of an emergency PDN connection to a trusted WLAN access, if this information is received from the 3GPP AAA Server, the user is a non-roaming authenticated user and the TWAN is configured to use a dynamic PGW for emergency services for such users;

– proceed during an Emergency Attach for a UE without a UICC or with an authenticated IMSI as specified above with the following modifications, if local policies (related with local regulations) in the TWAN allows unauthenticated emergency sessions:

– if the UE is UICC-less, the User Identity IE in the Authentication and Authorization Request shall contain the IMEI in Emergency NAI for Limited Service State format as defined in clause 19 of 3GPP TS 23.003 [14];

– if the Permanent User Identity IE in the answer contains an IMEI based NAI but the User Identity IE in the request did not contain an IMEI based NAI, the TWAN shall determine that the IMSI was not authenticated and proceed accordingly with the setup of the Emergency PDN connection over S2b (see 3GPP TS 29.274 [38]).

5.1.2.2 HSS/AAA Initiated Detach on STa

5.1.2.2.1 General

This procedure is used between the 3GPP AAA/HSS and the trusted non-3GPP access network to instruct the non-3GPP access network to detach a specific user from the access network. The procedure is based on Diameter session abort messages.

Diameter usage over the STa interface:

– This procedure is mapped to the Diameter command codes Diameter-Abort-Session-Request (ASR), Diameter‑Abort-Session-Answer (ASA), Diameter-Session-Termination-Request (STR) and Diameter-Session-Termination-Answer (STA) specified in IETF RFC 6733 [58]. Information element contents for these messages are shown in tables 5.1.2.2.1/1 and 5.1.2.2.1/2.

– The STa application id value of 16777250 shall be used as the Application Id in ASR/ASA/STR/STA commands.

Table 5.1.2.2.1/1: Information Elements passed in ASR message

Information element name	Mapping to Diameter AVP	Cat.	Description
Permanent User Identity	User-Name	M	This information element shall contain the permanent identity of the user. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15], and shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]. If this IE contains an identity based on IMSI, this IE shall not include the leading digit prepended in front of the IMSI used to differentiate between authentication schemes.
Auth-Session-State	Auth-Session-State	O	If present this information element shall indicate to the Non-3GPP access network whether the 3GPP AAA Server requires an STR message.

Table 5.1.2.2.1/2: Information Elements passed in ASA message

Information element name	Mapping to Diameter AVP	Cat.	Description
Result-Code	Result-Code	M	This IE shall indicate the result of the operation.

Table 5.1.2.2.1/3: Information Elements passed in STR message

Information element name	Mapping to Diameter AVP	Cat.	Description
Termination-Cause	Termination-Cause	M	This information element shall contain the reason why the session was terminated. It shall be set to "DIAMETER_ADMINISTRATIVE" to indicate that the session was terminated in response to an ASR message.

Table 5.1.2.2.1/4: Information Elements passed in STA message

Information element name	Mapping to Diameter AVP	Cat.	Description
Result-Code	Result-Code	M	This IE shall contain the result of the operation.

5.1.2.2.2 3GPP AAA Server Detailed Behaviour

The 3GPP AAA Server shall make use of this procedure to instruct the Non-3GPP access network to detach a specific user from the access network.

In the DSMIPv6 case, the 3GPP AAA Server shall initiate first the detach procedure over the S6b reference point towards the PDN GW. When this process has finalized, the 3GPP AAA Server can initiate the detach procedure of the UE from the non-3GPP access network.

The 3GPP AAA Server shall include the Auth-Session-State AVP in the ASR command with a value of NO_STATE_MAINTAINED if it does not require a STR from the Non-3GPP access network. If it does require a STR from the Non-3GPP access network, the 3GPP AAA Server shall either omit the Auth-Session-State AVP from the ASR command or include the Auth-Session-State AVP in the ASR command with a value of STATE_MAINTAINED.

On receipt of the ASR command, the Non-3GPP access network shall check if the user is known in the Non-3GPP access network. If not, Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN.

If the user is known, the Non-3GPP access network shall perform the disconnection of all the PDN connections active for this user and remove any stored user information, except for emergency PDN connections which shall remain active, if the trusted Non-3GPP access supports Emergency services for users in limited service state.

The Non-3GPP access network shall set the Result-Code to DIAMETER_SUCCESS and send back the ASA command to the 3GPP AAA Server, which shall update the status of the subscriber on the detached access network.

If required by the 3GPP AAA Server, the Non-3GPP access network shall send an STR with the Termination-Cause set to DIAMETER_ADMINISTRATIVE. The 3GPP AAA Server shall set the Result-Code to DIAMETER_SUCCESS and return the STA command to the Non-3GPP access network.

5.1.2.2.3 3GPP AAA Proxy Detailed Behaviour

When the 3GPP AAA Proxy receives the ASR from the 3GPP AAA Server it shall route the request to the non-3GPP access network.

If the 3GPP AAA Proxy requires an STR but the 3GPP AAA Server does not, the 3GPP AAA Proxy may override the value of the Auth-Session-State AVP in the ASR and set it to STATE_MAINTAINED. In this case, the 3GPP AAA Proxy shall not forward the STR received from the non-3GPP access network onto the 3GPP AAA Server and shall return an STA command to the non-3GPP access network with the Result-Code set to DIAMETER_SUCCESS. The 3GPP AAA Proxy shall not override the value of the Auth-Session-State AVP under any other circumstances.

On receipt of the ASA message with Diameter Result Code set to DIAMETER_SUCCESS, the 3GPP AAA Proxy shall route the successful response to the 3GPP AAA Server and shall release the resources associated with the session.

When the 3GPP AAA Proxy receives the STR from the Non-3GPP access network, it shall route the request to the 3GPP AAA Server. On receipt of the STA message, the 3GPP AAA Proxy shall route the response to the Non-3GPP access network.

5.1.2.3 STa Re-Authorization and Re-Authentication Procedures

5.1.2.3.1 General

The STa Re-Authorization procedure shall be used between the 3GPP AAA Server and the trusted non-3GPP access network for enabling:

– the 3GPP AAA Server to modify the previously provided authorization parameters. This may happen due to a modification of the subscriber profile in the HSS (for example, removal of a specific APN associated with the subscriber, or change of the identity of a dynamically allocated PDN GW, or change of the identity of a dynamically allocated PDN GW for emergency services, see clause 8.1.2.3). In this case, this procedure is performed in two steps:

– The 3GPP AAA server shall issue an STa Re-Auth request towards the trusted non-3GPP access network. Upon receipt of such a request, the trusted non-3GPP access network shall respond to the request and shall indicate the disposition of the request. This procedure is mapped to the Diameter command Re-Auth-Request and Re-Auth-Answer specified in IETF RFC 6733 [58]. Information element contents for these messages are shown in tables 5.1.2.3.1/1 and 5.1.2.3.1/2.

– Upon receiving the STa Re-Auth request, the non-3GPP access network shall immediately invoke the STa access authorization procedure, based on the reuse of the Diameter command codes AA-Request and AA-Answer commands specified in IETF RFC 4005 [4]. Information element contents for these messages are shown in tables 5.1.2.3.1/3 and 5.1.2.3.1/4.

– the trusted non-3GPP access network to retrieve the subscriber profile from the HSS. This procedure may be initiated at any time by the Trusted non-3GPP access network for check if there is any modification in the user authorization parameters previously provided by the 3GPP AAA Server. In this one-step procedure, the trusted non-3GPP access network shall invoke the STa access authorization procedure, based on the reuse of the Diameter commands AA-Request and AA-Answer commands IETF RFC 4005 [4]. Information element contents for these messages are shown in tables 5.1.2.3.1/3 and 5.1.2.3.1/4.

After receiving the authorization answer, the trusted non-3GPP access network will release the active PDN connections, for which the authorization has been revoked. If the authorization was rejected by the 3GPP AAA server (e.g. because the user’s subscription for non-3GPP accesses has been terminated), the non-3GPP access network shall detach the user from the non-3GPP access network and release all resources. If an emergency PDN connection is active and the trusted non-3GPP access supports emergency services for users in limited service state, the non-3GPP access network shall keep the user attached in the non-3GPP access and the emergency PDN connection active. The non-emergency resources shall be released.

The STa Re-Authentication procedure shall be used between the 3GPP AAA Server and the trusted non-3GPP access network for re-authenticating the user. This procedure may be initiated at any time by the 3GPP AAA Server based on HPLMN operator policies configured in the 3GPP AAA server. This procedure is performed in two steps:

– The 3GPP AAA server issues an STa Re-Auth request towards the trusted non-3GPP access. Upon receipt of such a request, the trusted non-3GPP access network shall respond to the request and indicate the disposition of the request. This procedure is mapped to the Diameter command Re-Auth-Request and Re-Auth-Answer specified in IETF RFC 6733 [58]. Information element contents for these messages are shown in tables 5.1.2.3.1/1 and 5.1.2.3.1/2.

– Upon receiving the STa Re-Auth request, the trusted non-3GPP access network shall immediately invoke the STa Access Authentication and Authorization procedure, based on the Re-Auth Request Type provided by the 3GPP AAA server. This procedure is mapped to the Diameter command codes based on the reuse of the Diameter commands Diameter-EAP-Request and Diameter-EAP-Answer specified in IETF RFC 4072 [5]. Information element contents for these messages are shown in tables 5.1.2.3.1/5 and 5.1.2.3.1/6.

If the re-authentication of the user is not successful, the trusted non-3GPP access network will release all the active PDN connections of the user, except for emergency PDN connections which shall remain active if the trusted non-3GPP access network supports Emergency services for users in limited service state. After a successful authentication and authorization procedure, the trusted non-3GPP access network shall release the active PDN connections for which the authorization has been revoked.

Table 5.1.2.3.1/1: STa Re-Auth request

Information element name	Mapping to Diameter AVP	Cat.	Description
Permanent User Identity	User-Name	M	This information element shall contain the permanent identity of the user. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15] and shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]. If this IE contains an identity based on IMSI, this IE shall not include the leading digit prepended in front of the IMSI used to differentiate between authentication schemes.
Re-Auth Request Type	Re-Auth–Request-Type	M	T This IE shall define whether the user is to be authorized only or authenticated and authorized. In this case, the following values shall be used: AUTHORIZE_AUTHENTICATE if the re-authentication of the user is requested; AUTHORIZE_ONLY if the update of the previously provided user authorization parameters is requested.
Routing Information	Destination-Host	M	This information element shall be obtained from the Origin-Host AVP, which was included in a previous command received from the trusted non-3GPP access.

Table 5.1.2.3.1/2: STa Re-Auth response

Information element name

Mapping to Diameter AVP

Cat.

Description

Permanent User Identity

User-Name

This information element shall contain the permanent identity of the user. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15] and shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]. If this IE contains an identity based on IMSI, this IE shall not include the leading digit prepended in front of the IMSI used to differentiate between authentication schemes.

Result

Result-Code / Experimental-Result

This IE shall contain the result of the operation.

The Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETF RFC 6733 [58]).

The Experimental-Result AVP shall be used for STa errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP.

Table 5.1.2.3.1/3: STa Authorization Request

Information element name	Mapping to Diameter AVP	Cat.	Description
Permanent User Identity	User-Name	M	This information element shall contain the permanent identity of the user. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15] and shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14] If this IE contains an identity based on IMSI, this IE shall not include the leading digit prepended in front of the IMSI used to differentiate between authentication schemes.
Request-Type	Auth-Request-Type	M	This IE shall define whether the user is to be authenticated only, authorized only or both. In this case, it shall have the value: AUTHORIZE_ONLY
Mobility Capabilities	MIP6-Feature-Vector	C	This information element shall contain the mobility capabilities of the non-3GPP access network. This AVP shall be included only if optimized idle mode mobility from E-UTRAN to HRPD access is executed. When included, the PMIP_SUPPORTED and the OPTIMIZED_IDLE_MODE_MOBILITY flags shall be set.
Routing Information	Destination-Host	M	The 3GPP AAA Server name shall be obtained from the Origin-Host AVP of a previously received message.
Access Network Information	Access-Network-Info	O	If present, this IE shall contain the identity and location information of the access network where the UE is attached.
Local Time Zone	Local-Time-Zone	O	If present, this IE shall contain the time zone of the location in the access network where the UE is attached.

Table 5.1.2.3.1/4: STa Authorization response

Information element name	Mapping to Diameter AVP	Cat.	Description
Registration Result	Result Code/ Experimental Result Code	M	This IE shall contain the result of the operation. The Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETF RFC 6733 [58]). The Experimental-Result AVP shall be used for STa errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP
Request-Type	Auth-Request-Type	M	It shall contain the value AUTHORIZE_ONLY. See IETF RFC 4072 [5].
Session Alive Time	Session-Timeout	O	This AVP may be present if the Result-Code AVP is set to DIAMETER _SUCCESS; if present, it shall contain the maximum number of seconds the user session is allowed to remain active. This AVP is defined in IETF RFC 6733 [58].
Accounting Interim Interval	Acct-Interim-Interval	O	If present, this IE shall contain the Charging duration.
Default APN	Context-Identifier	C	This AVP shall indicate the default APN for the user. It shall only be included if NBM is authorized for use, the Emergency-Indication AVP was not present in the initial Authentication and Authorization Answer and the Result-Code AVP is set to DIAMETER_SUCCESS.
APN-OI replacement	APN-OI-Replacement	C	This AVP shall indicate the domain name to replace the APN-OI in the non-roaming case or in the home routed roaming case when constructing the PDN GW FQDN upon which it needs to perform a DNS resolution. See 3GPP TS 23.003 [3]. It shall only be included if NBM is authorized for use, the Emergency-Indication bit of the Emergency-Services AVP was not set in the initial Authentication and Authorization Answer and the Result-Code AVP is set to DIAMETER_SUCCESS.
APN and PGW Data	APN-Configuration	C	This information element shall only be sent if the Emergency-Indication bit of the Emergency-Services AVP was not set in the initial Authentication and Authorization Answer and the Result-Code AVP is set to DIAMETER_SUCCESS. When NBM is authorized for use, this AVP shall contain the default APN, the list of authorized APNs, user profile information and PDN GW information. When local IP address assignment is used (for HBM), this AVP shall only be present if DHCP based Home Agent discovery is used and contain the Home Agent Information for discovery purposes. The Trusted Non-3GPP access network knows if NBM is authorized for use or if a local IP address (for HBM) is assigned based on the flags in the MIP6-Feature-Vector received during the STa access authentication and authorization procedure. APN-Configuration is a grouped AVP, defined in 3GPP TS 29.272 [29]. When NBM is authorized for use, the following information elements per APN may be included: – APN – APN-AMBR – Authorized 3GPP QoS profile – Statically allocated User IP Address (IPv4 and/or IPv6) – Allowed PDN types (IPv4, IPv6, IPv4v6, IPv4_OR_IPv6) – PDN GW identity – PDN GW allocation type – VPLMN Dynamic Address Allowed – Visited Network Identifier (see clause 5.1.2.1.4) When DSMIPv6 with HA discovery based on DHCPv6 is used, the following information elements per Home Agent may be included: – HA-APN (Home Agent APN as defined in 3GPP TS 23.003 [14]) – Authorized 3GPP QoS profile – PDN GW identity
UE Charging Data	3GPP-Charging-Characteristics	O	If present, this information element shall contain the type of charging method to be applied to the user (see 3GPP TS 29.061 [31]).
UE AMBR	AMBR	C	This Information Element shall contain the modified UE AMBR of the user. It shall be present if the Result-Code AVP is set to DIAMETER_SUCCESS and ANID is "HRPD".
Mobility Capabilities	MIP6-Feature-Vector	C	This information element shall only be sent if it has been received in the corresponding authorization request and the Result-Code AVP is set to DIAMETER_SUCCESS. When included, the PMIP_SUPPORTED and the OPTIMIZED_IDLE_MODE_MOBILITY flags shall be set.
Trace information	Trace-Info	C	This AVP shall be included if the subscriber and equipment trace has been activated for the user in the HSS and signalling based activation is used to download the trace activation from the HSS to the trusted non-3GPP access network. Only the Trace-Data AVP shall be included to the Trace-Info AVP and shall contain the following AVPs: – Trace-Reference – Trace-Depth-List – Trace-Event-List, for PGW – Trace-Collection-Entity The following AVPs may also be included in the Trace-Data AVP: – Trace-Interface-List, for PGW, if this AVP is not present, trace report generation is requested for all interfaces for PGW listed in 3GPP TS 32.422 [32] – Trace-NE-Type-List, with the only allowed value being "PDN GW". If this AVP is not included, trace activation in PDN GW is required.
MSISDN	Subscription-ID	C	This AVP shall contain the MSISDN of the UE and shall be sent if it is available and the Result-Code AVP is set to DIAMETER_SUCCESS.
Emergency Info	Emergency-Info	C	This IE shall contain the identity of the PDN GW dynamically allocated for emergency services. It shall be present for a non-roaming authenticated user, if this information was received from the HSS, the TWAN indicated support of IMS Emergency Sessions and the Result-Code AVP is set to DIAMETER_SUCCESS.
UE Usage Type	UE-Usage-Type	C	This IE shall be present if this information is available in the user subscription. When present, this IE shall contain the UE Usage Type of the subscriber.

Table 5.1.2.3.1/5: STa Access Authentication and Authorization 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. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15] and it shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]. This IE shall include the leading digit used to differentiate between authentication schemes.
EAP payload	EAP-payload	M	This IE shall contain the Encapsulated EAP payload used for the UE – 3GPP AAA Server mutual authentication
Authentication Request Type	Auth-Request-Type	M	This IE shall define whether the user is to be authenticated only, authorized only or both. In this case, it shall have the value AUTHORIZE_AUTHENTICATE.

Table 5.1.2.3.1/6: Trusted non-3GPP Access Authentication and Authorization Answer

Information element name	Mapping to Diameter AVP	Cat.	Description
User Identity	User-Name	M	This information element shall contain the identity of the user. The identity shall be represented in NAI form as specified in IETF RFC 4282 [15] and it shall be formatted as defined in clause 19 of 3GPP TS 23.003 [14]. This IE shall include the leading digit used to differentiate between authentication schemes, if it contains a NAI other than an Emergency NAI for Limited Service State.
EAP payload	EAP payload	M	This IE shall contain the Encapsulated EAP payload used for UE- 3GPP AAA Server mutual authentication.
Authentication Request Type	Auth-Request-Type	M	It shall contain the value AUTHORIZE_AUTHENTICATE. See IETF RFC 4072 [5].
Result code	Result-Code / Experimental Result Code	M	This IE shall contain the result of the operation. Result codes are as in Diameter base protocol (see IETF RFC 6733 [58]). Experimental-Result AVP shall be used for STa errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP.
Session Alive Time	Session-Timeout	O	This AVP may be present if the Result-Code AVP is set to DIAMETER _SUCCESS; if present, it contains the maximum number of seconds the user session is allowed to remain active. This AVP is defined in IETF RFC 6733 [58].
Accounting Interim Interval	Accounting Interim-Interval	O	If present, this IE shall contain the Charging duration.
Pairwise Master Key	EAP-Master-Session-Key	C	This IE shall be sent if Result-Code AVP is set to DIAMETER_SUCCESS.
Default APN	Context-Identifier	C	This AVP shall indicate the default APN for the user. It shall only be included if NBM is authorized for use, the Emergency-Indication bit of the Emergency-Services AVP was not set in the initial Authentication and Authorization Answer and the Result-Code AVP is set to DIAMETER_SUCCESS.
APN-OI replacement	APN-OI-Replacement	C	This AVP shall indicate the domain name to replace the APN-OI in the non-roaming case or in the home routed roaming case when constructing the PDN GW FQDN upon which it needs to perform a DNS resolution. See 3GPP TS 23.003 [3]. It shall only be included if NBM is authorized for use, the Emergency-Indication bit of the Emergency-Services AVP was not set in the initial Authentication and Authorization Answer and the Result-Code AVP is set to DIAMETER_SUCCESS.
APN and PGW Data	APN-Configuration	C	This information element shall only be sent if the non-3GPP access network was decided to be trusted, the Emergency-Indication bit of the Emergency-Services AVP was not set in the initial Authentication and Authorization Answer and the Result-Code AVP is set to DIAMETER_SUCCESS. When NBM is authorized for use this AVP shall contain the default APN, the list of authorized APNs, user profile information and PDN GW information. When local IP address assignment is used (for HBM), this AVP shall only be present if DHCP based Home Agent discovery is used and contain the Home Agent Information for discovery purposes. The trusted non-3GPP access network knows if NBM is authorized for use or if a local IP address (for HBM) is assigned based on the flags in the MIP6-Feature-Vector. APN-Configuration is a grouped AVP, defined in 3GPP TS 29.272 [29]. When NBM is authorized for use, the following information elements per APN may be included: – APN – APN-AMBR – Authorized 3GPP QoS profile – User IP Address (IPv4 and/or IPv6) – Allowed PDN types (IPv4, IPv6, IPv4v6, IPv4_OR_IPv6) – PDN GW identity – PDN GW allocation type – VPLMN Dynamic Address Allowed – APN-AMBR – Visited Network Identifier (see clause 5.1.2.1.4) When DSMIPv6 with HA discovery based on DHCPv6 is used, the following information elements per Home Agent may be included: – HA-APN (Home Agent APN as defined in 3GPP TS 23.003 [14]) – Authorized 3GPP QoS profile – PDN GW identity
UE Charging Data	3GPP-Charging-Characteristics	O	If present, this information element shall contain the type of charging method to be applied to the user (see 3GPP TS 29.061 [31]).
UE AMBR	AMBR	C	This Information Element shall contain the UE AMBR of the user. It shall be present only if the non-3GPP access network was decided to be trusted, the Result-Code AVP is set to DIAMETER_SUCCESS and ANID is "HRPD".
FA-RK	MIP-FA-RK	C	This AVP shall be present if MIPv4 is used, MN-FA authentication extension is supported and the Result-Code AVP is set to DIAMETER_SUCCESS.
FA-RK-SPI	MIP-FA-RK-SPI	C	This AVP shall be present if MIP-FA-RK is present
Trace information	Trace-Info	C	This AVP shall be included if the subscriber and equipment trace has been activated for the user in the HSS and signalling based activation is used to download the trace activation from the HSS to the trusted non-3GPP access network. Only the Trace-Data AVP shall be included to the Trace-Info AVP and shall contain the following AVPs: – Trace-Reference – Trace-Depth-List – Trace-Event-List, for PGW – Trace-Collection-Entity The following AVPs may also be included in the Trace-Data AVP: – Trace-Interface-List, for PGW, if this AVP is not present, trace report generation is requested for all interfaces for PGW listed in 3GPP TS 32.422 [32] – Trace-NE-Type-List, with the only allowed value being "PDN GW". If this AVP is not included, trace activation in PDN GW is required.
MSISDN	Subscription-ID	C	This AVP shall contain the MSISDN of the UE and shall be sent if it is available and the Result-Code AVP is set to DIAMETER_SUCCESS.
WLCP Key	WLCP-Key	C	This IE shall be present if the Result-Code AVP is set to DIAMETER_SUCCESS and the TWAN Connection Mode previously selected is MCM. If present, it shall contain the key for protecting WLCP signalling (see 3GPP TS 33.402 [19]).
Emergency Info	Emergency-Info	C	This IE shall contain the identity of the PDN GW dynamically allocated for emergency services. It shall be present for a non-roaming authenticated user, if this information was received from the HSS, the TWAN indicated support of IMS Emergency Sessions and the Result-Code AVP is set to DIAMETER_SUCCESS.
UE Usage Type	UE-Usage-Type	C	This IE shall be present if this information is available in the user subscription. When present, this IE shall contain the UE Usage Type of the subscriber.

5.1.2.3.2 3GPP AAA Server Detailed Behaviour

Handling of Re-Auth Request:

The 3GPP AAA Server shall make use of this procedure to indicate the following:

– If the relevant service authorization information shall be updated in the Trusted non-3GPP access network, the Re‑Auth‑Request‑Type shall be set to AUTHORIZE_ONLY. This procedure may be triggered by the HSS sending a subscription data update (refer to clause 8.1.2.3) or by local policies, e.g. periodic re-authorization configured by the operator. As for the STa reference point, only a single Diameter authorization session is used for a user, this procedure is initiated for all the PDN connections of this user, i.e. a single instance of Re-authorization Request shall be used per user.

– If the re-authentication and re-authorization of the user shall be executed, the Re‑Auth‑Request‑Type shall be set to AUTHORIZE_AUTHENTICATE. This procedure may be triggered e.g. by the expiration of a timer started at the successful completion of the last (re-)authentication of the user, depending on the local policies configured in the 3GPP AAA Server.

Handling of Authorization Request:

The 3GPP AAA Server shall check that the user exists in the 3GPP AAA Server. The check shall be based on Diameter Session-Id. If not, Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN. If the user exists, the 3GPP AAA Server shall perform the authorization checking described in clause 5.1.2.1.2.

If the Authorization request contained the MIP6-Feature-Vector with the OPTIMIZED_IDLE_MODE_MOBILITY flag set, the 3GPP AAA server shall request the user data from the HSS, in order to retrieve up-to-date PDN GW information.

Handling of Authentication and Authorization Requests:

The 3GPP AAA Server shall execute the re-authentication of the user, using a full authentication or fast re-authentication, as described in 3GPP TS 33.402 [19], clause 6.2 and 6.3. If full authentication is executed and there are no valid authentication vectors for the given non-3GPP access network available in the 3GPP AAA Server, it shall fetch authentication vectors from the HSS. A combined authentication and authorization shall be executed, with reduced message content described in Tables 5.1.2.3.1/5 and 5.1.2.3.1/6. The QoS-Capability, Access Network Identity, Access Type, Visited Network Identifier, Terminal Information elements received during the initial authentication and authorization procedure as well as the trustworthiness of the non-3GPP AN and the IP mobility mode selected during that procedure shall be considered as valid. If re-authentication of the user is successful and MIPv4 FACoA mode is used the 3GPP AAA Server shall create the MIPv4 FACoA security parameters as defined in 3GPP TS 33.402 [19].

If the re-authentication of the user is unsuccessful, the 3GPP AAA Server shall:

– Terminate all S6b authorization sessions connected to the user, as described in clause 9.1.2.4

– Remove all APN-PDN GW bindings from the HSS, as described in clauses 8.1.2.2.2.1 and 8.1.2.2.2.2.

– De-register the user from the HSS, as described in clauses 8.1.2.2.2.1 and 8.1.2.2.2.2. Depending on the cause of the re-authentication being unsuccessful, the Server Assignment Type shall be set to AUTHENTICATION_FAILURE or AUTHENTICATION_TIMEOUT.

– Release all resources connected to the user.

5.1.2.3.3 3GPP AAA Proxy Detailed Behaviour

The 3GPP AAA Proxy is required to handle roaming cases in which the Non-3GPP access network is in the VPLMN. The 3GPP AAA Proxy shall act as a stateful proxy, with the following additions.

When forwarding the authorization answer or the authentication and authorization answer, the 3GPP AAA Proxy

– shall record the state of the connection (i.e. Authentication and Authorization Successful).

5.1.2.3.4 Trusted Non-3GPP Access Network Detailed Behaviour

Upon receiving the re-auth request, the Trusted non-3GPP access network shall perform the following checks and if an error is detected, the non-3GPP access network shall stop processing the request and return the corresponding error code.

Check the Re-Auth–Request-Type AVP:

1) If it indicates AUTHENTICATE_ONLY, Result-Code shall be set to DIAMETER_INVALID_AVP_VALUE.

2) If it indicates AUTHORIZE_AUTHENTICATE, the authentication and authorization of the user is initiated, as defined in 3GPP TS 33.402, with the Diameter message contents described by Tables 5.1.2.3.1/5 and 5.1.2.3.1/6.

3) If it indicates AUTHORIZE_ONLY, the non-3GPP access network shall just perform an authorization procedure as described by Tables 5.1.2.3.1/3 and 5.1.2.3.1/4.

After successful authorization or authentication and authorization procedure, the trusted non-3GPP access network shall overwrite, for the subscriber identity indicated in the request and the received session, the current authorization information with the information received from the 3GPP AAA Server.

For the TWAN access, if the TWAN receives the PDN GW Identity from 3GPP AAA Server which is different from the currently selected PDN GW for the same APN, the TWAN shall not tear down the existing PDN connection.

If the TWAN supports Dedicated Core Networks and receives the UE-Usage-Type from the 3GPP AAA Server, the TWAN shall select the PGW as specified in clause 5.8 of 3GPP TS 29.303 [34] for new PDN connections.

The release of a PDN connection shall be initiated if the user’s subscription for the APN belonging to an active PDN connection has been terminated.

If the authorization or authentication and authorization procedure was unsuccessful, the non-3GPP access network shall detach the user from the non-3GPP access and release all resources. If the trusted non-3GPP access supports emergency services for users in limited service state, and there is an emergency PDN connection active for such user, the non-3GPP access network shall keep the user attached in the non-3GPP access and the emergency PDN connection active. The non-emergency resources shall be released.

The Trusted Non-3GPP access network shall initiate the re-authorization of the user in a one-step procedure (i.e. without receiving a re-authorization request from the AAA Server) if the PDN GW information needs to be updated for optimized idle mode mobility from E-UTRAN to HRPD access.

If GTPv2 is used on S2a and if the Trace-Info AVP including Trace-Data has been received in the authorization response, the trusted non-3GPP access network shall send a GTPv2 Trace Session Activation message (see 3GPP TS 29.274 [38]) to the PGW to start a trace session for the user. If the Trace-Info AVP including Trace-Reference (directly under the Trace-Info) has been received in the authorization response, the trusted non-3GPP access network shall send a GTPv2 Trace Session Deactivation message to the PGW to stop the ongoing trace session, identified by the Trace-Reference. For details, see 3GPP TS 32.422 [32].

For the TWAN access, the TWAN shall send the identification, location information of the Access Point where the UE is attached, and the local time zone of the UE, in the authorization request towards the 3GPP AAA Server that follows a re-authorization request issued by the 3GPP AAA Server to the TWAN.

5.1.2.4 Non-3GPP Access Network Initiated Session Termination

5.1.2.4.1 General

The STa reference point allows the non-3GPP access network to inform the 3GPP AAA server that the session resources of the non-3GPP access network assigned to a given user are being released.

The procedure shall be initiated by the non-3GPP access network and removes non-3GPP access information from the 3GPP AAA Server. These procedures are based on the reuse of Diameter STR and STA commands as specified in IETF RFC 6733 [58].

Table 5.1.2.4.1/1: STa Session Termination Request

Information Element name	Mapping to Diameter AVP	Cat.	Description
Permanent User Identity	User-Name	M	This information element shall contain the permanent identity of the user in NAI format as defined in clause 19 of 3GPP TS 23.003 [14]. If this IE contains an identity based on IMSI, this IE shall not include the leading digit prepended in front of the IMSI used to differentiate between authentication schemes.
Termination Cause	Termination-Cause	M	This IE shall contain the reason for the disconnection.

Table 5.1.2.4.1/2: STa Session Termination Answer

Information Element name

Mapping to Diameter AVP

Cat.

Description

Result

Result-Code / Experimental-Result

This IE shall contain the result of the operation.

The Result-Code AVP shall be used for errors as defined in the Diameter base protocol (see IETF RFC 6733 [58]).

Experimental-Result AVP shall be used for STa errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP.

5.1.2.4.2 3GPP AAA Server Detailed Behaviour

Upon reception of the Session Termination Request message from the non-3GPP access network, the 3GPP AAA Server shall check that there is an ongoing session associated to the two parameters received (Session-Id and User-Name).

If an active session is found and it belongs to the user identified by the User-Name parameter, the 3GPP AAA Server shall deregister itself as the managing 3GPP AAA Server for the subscriber following the procedures listed in 8.1.2.2.2. In case of a deregistration success, the 3GPP AAA Server shall release the session resources associated to the specified session and a Session Termination Response shall be sent to the non-3GPP access network, indicating DIAMETER_SUCCESS. If deregistration from the HSS fails, the 3GPP AAA Server shall return a Session-Termination Response with the Diameter Error DIAMETER_UNABLE_TO_COMPLY.

Otherwise, the 3GPP AAA Server returns a Session Termination Response with the Diameter Error DIAMETER_UNKNOWN_SESSION_ID

5.1.2.4.3 3GPP AAA Proxy Detailed Behaviour

The 3GPP AAA Proxy is required to handle roaming cases in which the non-3GPP access network is located in the VPLMN. The 3GPP AAA Proxy shall act as a stateful proxy.

On receipt of the Session Termination Request message from the non-3GPP access network, the 3GPP AAA Proxy shall route the message to the 3GPP AAA Server.

On receipt of the Session Termination Answer message from the 3GPP AAA Server, the 3GPP AAA Proxy shall route the message to the non-3GPP access network and it shall release any local resources associated to the specified session only if the result code is set to DIAMETER_SUCCESS.

5.1.2.5 ERP Re-Authentication in Non-3GPP Access

5.1.2.5.1 General

The STa reference point allows the non-3GPP access network to perform re-authentication using ERP.

ERP allows the UE and the ER server to mutually verify proof of possession of key material derived from a previous successful EAP authentication and to establish a security association between the UE and the non-3GPP access network.

When this procedure is used, the ER server is collocated either with a TWAP or the 3GPP AAA Proxy or the 3GPP AAA Server. When the ER is located in the TWAP, ERP re-authentication procedures are out of the scope of this specification.

When ERP is used, the ERP re-authentication procedure shall be mapped to the Diameter-EAP-Request and Diameter-EAP-Answer command codes specified in IETF RFC 4072 [5].

Table 5.1.2.5.1/1: STa ERP Re-authentication Request

Information element name	Mapping to Diameter AVP	Cat.	Description
KeyName-NAI	User-Name	M	This information element shall contain the KeyName-NAI (as defined in clause 19.3.8 of 3GPP TS 23.003 [14]) in the context of EAP re-authentication using ERP as described in IETF RFC 6696 [55] and 3GPP TS 33.402 [19].
EAP-Initiate	EAP-payload	M	This IE shall contain the EAP-Initiate/Re-auth message used for the UE – ER Server mutual authentication.
Authentication Request Type	Auth-Request-Type	M	This IE defines whether the user is to be authenticated only, authorized only or both. AUTHORIZE_AUTHENTICATE shall be used in this case.
DER-Flags	DER-Flags	M	This Information Element contains a bit mask. See clause 5.2.3.20.

Table 5.1.2.5.1/2: STa ERP Re-authentication Answer

Information element name	Mapping to Diameter AVP	Cat.	Description
KeyName-NAI	User-Name	M	This information element shall contain the KeyName-NAI (as defined in clause 19.3.8 of 3GPP TS 23.003 [14]) in the context of EAP re-authentication using ERP as described in IETF RFC 6696 [55] and 3GPP TS 33.402 [19].
EAP-Finish	EAP payload	O	If present, this IE shall contain the EAP-Finish as described in IETF RFC 6942 [57].
Authentication Request Type	Auth-Request-Type	M	It shall contain the value AUTHORIZE_AUTHENTICATE. See IETF RFC 4072 [5].
Result code	Result-Code / Experimental Result Code	M	This IE shall contain the result of the operation. Result codes are as in Diameter Base Protocol (IETF RFC 3588 [7]). Experimental-Result AVP shall be used for STa errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP.
ERP Keying Material	Key	C	This IE shall be present if the ERP re-authentication is successful. In that case, this IE shall contain the Re-authentication MSK (rMSK) derived by ERP and may contain the rMSK lifetime.

5.1.2.5.2 ER server located in 3GPP AAA Proxy or 3GPP AAA Server Detailed Behaviour

Upon reception of the ERP re-authentication request from the non-3GPP access network, the 3GPP AAA Proxy or the 3GPP AAA Server acting as ER server shall search in its local database for a valid, unexpired root key matching the keyName part of the KeyName-NAI.

If the root key is not found, the 3GPP AAA Proxy or 3GPP AAA Server shall set the Result-Code to DIAMETER_UNABLE_TO_COMPLY and the answer shall include an EAP-Payload AVP encapsulating an EAP Failure indicating that the ERP re-authentication has failed.

If such root key is found, the 3GPP AAA Server shall generate the ERP keying material as described in IETF RFC 6696 [55], shall include the requested ERP keying material in the answer and the result code shall be set to DIAMETER_SUCCESS.

NOTE: Only the ERP Implicit Bootstrapping mode defined in IETF RFC 6696 [55] is supported in this release.

5.1.2.5.3 3GPP AAA Proxy Detailed Behaviour

Upon reception of the ERP authentication request from the non-3GPP access network, the 3GPP AAA Proxy shall check if the realm part of the KeyName-NAI is its own domain name. If not, the Result-Code shall be set to DIAMETER_UNABLE_TO_COMPLY.

If the keyName part of the KeyName-NAI is its own domain name, the 3GPP AAA Proxy shall behave as described in clause 5.1.2.5.2.

NOTE: In roaming case, the location of the ER server in the home 3GPP AAA Server is not supported in this release.

5.2 Protocol Specification

5.2.1 General

The STa reference point shall be based on Diameter, as defined in IETF RFC 6733 [58], and contain the following additions and extensions:

– IETF RFC 4005 [4], which defines a Diameter protocol application used for Authentication, Authorization and Accounting (AAA) services in the Network Access Server (NAS) environment.

– IETF RFC 4072 [5], which provides a Diameter application to support the transport of EAP (IETF RFC 3748 [8]) frames over Diameter.

– IETF RFC 5779 [2], which defines a Diameter extensions and application for PMIPv6 MAG to AAA and LMA to AAA interfaces.

– IETF RFC 5447 [6], which defines Diameter extensions for Mobile IPv6 NAS to AAA interface.

In the case of a trusted non-3GPP IP access where PMIPv6 is used as mobility protocol, the MAG to 3GPP AAA server or the MAG to 3GPP AAA proxy communication shall use the MAG to AAA interface functionality defined in IETF RFC 5779 [2] and the NAS to AAA interface functionality defined in IETF RFC 5447 [6].

The trusted non-3GPP access network to AAA interface functionality over the STa reference defines a new Application Id:

– "STa" with value 16777250.

The STa application reuses existing EAP (IETF RFC 4072 [5]) application commands, command ABNFs, and application logic and procedures.

5.2.2 Commands

5.2.2.1 Commands for STa PMIPv6 or GTPv2 or ERP (re-)authentication and authorization procedures

5.2.2.1.1 Diameter-EAP-Request (DER) Command

The Diameter-EAP-Request (DER) command, indicated by the Command-Code field set to 268 and the "R" bit set in the Command Flags field, is sent from a non-3GPP access network NAS to a 3GPP AAA server. The ABNF is re-used from the IETF RFC 5779 [2].

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

< Session-Id >

[ DRMP ]

{ Auth-Application-Id }

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

[ Destination-Host ]

{ Auth-Request-Type }

{ EAP-Payload }

[ User-Name ]

[ Calling-Station-Id ]

…

[ RAT-Type ]

[ ANID ]

[ Full-Network-Name ]

[ Short-Network-Name ]

[ QoS-Capability ]

[ MIP6-Feature-Vector ]

[ Visited-Network-Identifier ]

[ Service-Selection ]

[ Terminal-Information ]

[ OC-Supported-Features ]

*[ Supported-Features ]

[ AAA-Failure-Indication ]

[ WLAN-Identifier ]

[ DER-Flags ]

[ TWAN-Connection-Mode ]

[ TWAN-Connectivity-Parameters ]

* 2 [ TWAG-CP-Address ]

[ ERP-RK-Request ]

…

*[ AVP ]

5.2.2.1.2 Diameter-EAP-Answer (DEA) Command

The Diameter-EAP-Answer (DEA) command, indicated by the Command-Code field set to 268 and the "R" bit cleared in the Command Flags field, is sent from a 3GPP AAA Server to a non-3GPP access network NAS. The ABNF is re-used from the IETF RFC 5779 [2]. The ABNF also contains AVPs that are reused from IETF RFC 4072 [5].

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

< Session-Id >

[ DRMP ]

{ Auth-Application-Id }

{ Result-Code }

[ Experimental-Result ]

{ Origin-Host }

{ Origin-Realm }

{ Auth-Request-Type }

[ EAP-Payload ]

[ User-Name ]

[ Session-Timeout ]

[ Accounting-Interim-Interval ]

[ EAP-Master-Session-Key ]

[ Context-Identifier ]

[ APN-OI-Replacement ]

*[ APN-Configuration ]

[MIP6-Agent-Info ]

[ MIP6-Feature-Vector ]

[ Mobile-Node-Identifier ]

[ 3GPP-Charging-Characteristics ]

[ AMBR ]

*[ Redirect-Host ]

[ AN-Trusted ]

[ Trace-Info ]

[ Subscription-ID ]

[ OC-Supported-Features ]

[ OC-OLR ]

*[ Load ]

*[ Supported-Features ]

[ MIP-FA-RK ]

[ MIP-FA-RK-SPI ]

[ NSWO-Authorization ]

[ DEA-Flags ]

[ TWAN-Connection-Mode ]

[ TWAN-Connectivity-Parameters ]

[ WLCP-Key ]

[ Terminal-Information ]

[ UE-Usage-Type ]

[ Emergency-Services ]

[ Emergency-Info ]

[ Key ]

[ ERP-Realm ]

…

*[ AVP ]

5.2.2.2 Commands for STa HSS/AAA Initiated Detach for Trusted non-3GPP Access

5.2.2.2.1 Abort-Session-Request (ASR) Command

The Abort-Session-Request (ASR) command, indicated by the Command-Code field set to 274 and the "R" bit set in the Command Flags field, is sent from a 3GPP AAA Server/Proxy to a non-3GPP access network NAS. ABNF for the ASR commands is as follows:

< Abort-Session-Request > ::= < Diameter Header: 274, REQ, PXY, 16777250 >

< Session-Id >

[ DRMP ]

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Destination-Host }

{ Auth-Application-Id }

[ User-Name ]

[ Auth-Session-State ]

…

*[ AVP ]

5.2.2.2.2 Abort-Session-Answer (ASA) Command

The Abort-Session-Answer (ASA) command, indicated by the Command-Code field set to 274 and the "R" bit cleared in the Command Flags field, is sent from a non-3GPP access network NAS to a 3GPP AAA Server/Proxy. ABNF for the ASA commands is as follows:

< Abort-Session-Answer > ::= < Diameter Header: 274, PXY, 16777250 >

< Session-Id >

[ DRMP ]

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

…

*[ AVP ]

5.2.2.2.3 Session-Termination-Request (STR) Command

The Session-Termination-Request (STR) command, indicated by the Command-Code field set to 275 and the "R" bit set in the Command Flags field, is sent from a trusted non-3GPP access network to a 3GPP AAA Server/Proxy. The Command Code value and ABNF are re-used from the IETF RFC 6733 [58], Session-Termination-Request command.

<Session-Termination-Request> ::= < Diameter Header: 275, REQ, PXY, 16777250 >

< Session-Id >

[ DRMP ]

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

[ Destination-Host ]

{ Auth-Application-Id }

{ Termination-Cause }

[ User-Name ]

[ OC-Supported-Features ]

…

*[ AVP ]

5.2.2.2.4 Session-Termination-Answer (STA) Command

The Session-Termination-Answer (STA) command, indicated by the Command-Code field set to 275 and the "R" bit cleared in the Command Flags field, is sent from a 3GPP AAA Server/Proxy to a trusted non-3GPP access network. The Command Code value and ABNF are re-used from the IETF RFC 6733 [58], Session-Termination-Answer command.

<Session-Termination-Answer> ::= < Diameter Header: 275, PXY, 16777250 >

< Session-Id >

[ DRMP ]

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

[ OC-Supported-Features ]

[ OC-OLR ]

*[ Load ]

*[ AVP ]

5.2.2.3 Commands for Re-Authentication and Re-Authorization Procedure

5.2.2.3.1 Re-Auth-Request (RAR) Command

The Diameter Re-Auth-Request (RAR) command, indicated by the Command-Code field set to 258 and the "R" bit set in the Command Flags field, is sent from a 3GPP AAA Server to a Trusted Non-3GPP access network. ABNF for the RAR command is as follows:

< Re-Auth-Request > ::= < Diameter Header: 258, REQ, PXY, 16777250 >

< Session-Id >

[ DRMP ]

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Destination-Host }

{ Auth-Application-Id }

{ Re-Auth-Request-Type }

[ User-Name ]

…

*[ AVP ]

5.2.2.3.2 Re-Auth-Answer (RAA) Command

The Diameter Re-Auth-Answer (ASA) command, indicated by the Command-Code field set to 258 and the "R" bit cleared in the Command Flags field, is sent from a Trusted Non-3GPP access network to a 3GPP AAA Server/Proxy. ABNF for the RAA commands is as follows:

< Re-Auth-Answer > ::= < Diameter Header: 258, PXY, 16777250 >

< Session-Id >

[ DRMP ]

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

…

*[ AVP ]

5.2.2.3.3 AA-Request (AAR) Command

The AA-Request (AAR) command, indicated by the Command-Code field set to 265 and the "R" bit set in the Command Flags field, is sent from a Trusted Non-3GPP access network to a 3GPP AAA Server/Proxy. The ABNF is re-used from IETF RFC 4005 [4], adding AVPs from IETF RFC 5779 [2].

< AA-Request > ::= < Diameter Header: 265, REQ, PXY, 16777250 >

< Session-Id >

[ DRMP ]

{ Auth-Application-Id }

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Auth-Request-Type }

[ Destination-Host ]

[ User-Name ]

[ MIP6-Feature-Vector ]

[ Access-Network-Info ]

[ Local-Time-Zone ]

[ OC-Supported-Features ]

…

*[ AVP ]

5.2.2.3.4 AA-Answer (AAA) Command

The AA-Answer (AAA) command, indicated by the Command-Code field set to 265 and the "R" bit cleared in the Command Flags field, is sent from a 3GPP AAA Server/Proxy to a Trusted Non-3GPP access network. The ABNF is re-used from IETF RFC 4005 [4], adding AVPs from IETF RFC 5779 [2].

< AA-Answer > ::= < Diameter Header: 265, PXY, 16777250 >

< Session-Id >

[ DRMP ]

{ Auth-Application-Id }

{ Auth-Request-Type }

{ Result-Code }

[ Experimental-Result ]

{ Origin-Host }

{ Origin-Realm }

[ Session-Timeout ]

[ Accounting-Interim-Interval ]

[ Context-Identifier ]

[ APN-OI-Replacement ]

*[ APN-Configuration ]

[ 3GPP-Charging-Characteristics ]

[ Trace-Info ]

[ Subscription-ID ]

[ OC-Supported-Features ]

[ OC-OLR ]

[ UE-Usage-Type ]

[ Emergency-Info]

*[ Load ]

…

*[ AVP ]

5.2.2.3.5 Diameter-EAP-Request (DER) Command

Refer to clause 5.2.2.1.1

5.2.2.3.6 Diameter-EAP-Answer (DEA) Command

Refer to clause 5.2.2.1.2

5.2.2.4 Commands for Trusted non-3GPP Access network Initiated Session Termination

5.2.2.4.1 Session-Termination-Request (STR) Command

The Session-Termination-Request (STR) command, indicated by the Command-Code field set to 275 and the "R" bit set in the Command Flags field, is sent from a non-3GPP access network to a 3GPP AAA server. The Command Code value and ABNF are re-used from the IETF RFC 6733 [58], Session-Termination-Request command.

<Session-Termination-Request> ::= < Diameter Header: 275, REQ, PXY, 16777250 >

< Session-Id >

[ DRMP ]

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

[ Destination-Host ]

{ Auth-Application-Id }

{ Termination-Cause }

[ User-Name ]

[ OC-Supported-Features ]

…

*[ AVP ]

5.2.2.4.2 Session-Termination-Answer (STA) Command

The Session-Termination-Answer (STA) command, indicated by the Command-Code field set to 275 and the "R" bit cleared in the Command Flags field, is sent from a 3GPP AAA server to a non-3GPP access network. The Command Code value and ABNF are re-used from the IETF RFC 6733 [58], Session-Termination-Answer command.

<Session-Termination-Answer> ::= < Diameter Header: 275, PXY, 16777250 >

< Session-Id >

[ DRMP ]

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

[ OC-Supported-Features ]

[ OC-OLR ]

*[ Load ]

*[ AVP ]

5.2.3 Information Elements

5.2.3.1 General

The following table describes the Diameter AVPs defined for the STa interface protocol in NBM mode, their AVP Code values, types, possible flag values and whether or not the AVP may be encrypted.

For all AVPs which contain bit masks and are of the type Unsigned32, bit 0 shall be the least significant bit. For example, to get the value of bit 0, a bit mask of 0x00000001 should be used.

Table 5.2.3.1/1: Diameter STa AVPs

				AVP Flag rules
Attribute Name	AVP Code	Clause defined	Value Type	Must	May	Should not	Must not
MIP6-Feature-Vector	124	5.2.3.3	Unsigned64	M			V,P
QoS-Capability	578	5.2.3.4	Grouped	M			V,P
Service-Selection	493	5.2.3.5	UTF8String	M			V,P
RAT-Type	1032	5.2.3.6	Enumerated	M,V			P
ANID	1504	5.2.3.7	UTF8String	M,V			P
AN-Trusted	1503	5.2.3.9	Enumerated	M,V			P
MIP-FA-RK	1506	5.2.3.12	OctetString	M,V			P
MIP-FA-RK-SPI	1507	5.2.3.13	Unsigned32	M,V			P
Full-Network-Name	1516	5.2.3.14	OctetString	V			M,P
Short-Network-Name	1517	5.2.3.15	OctetString	V			M,P
WLAN-Identifier	1509	5.2.3.18	Grouped	V			M,P
Mobile-Node-Identifier	506	5.2.3.2	UTF8String	M			V,P
AAA-Failure-Indication	1518	8.2.3.21	Unsigned32	V			M,P
Transport-Access-Type	1519	5.2.3.19	Enumerated	V			M,P
APN-Configuration	1430	8.2.3.7	Grouped	M,V			P
Visited-Network-Identifier	600	9.2.3.1.2	OctetString	M,V			P
DER-Flags	1520	5.2.3.20	Unsigned32	V			M,P
DEA-Flags	1521	5.2.3.21	Unsigned32	V			M,P
SSID	1524	5.2.3.22	UTF8String	V			M,P
HESSID	1525	5.2.3.23	UTF8String	V			M,P
Access-Network-Info	1526	5.2.3.24	Grouped	V			M,P
TWAN-Connection-Mode	1527	5.2.3.25	Unsigned32	V			M,P
TWAN-Connectivity-Parameters	1528	5.2.3.26	Grouped	V			M,P
Connectivity-Flags	1529	5.2.3.27	Unsigned32	V			M,P
TWAN-PCO	1530	5.2.3.28	OctetString	V			M,P
TWAG-CP-Address	1531	5.2.3.29	Address	V			M,P
TWAG-UP-Address	1532	5.2.3.30	UTF8String	V			M,P
TWAN-S2a-Failure-Cause	1533	5.2.3.31	Unsigned32	V			M,P
SM-Back-Off-Timer	1534	5.2.3.32	Unsigned32	V			M,P
WLCP-Key	1535	5.2.3.33	OctetString	V			M,P
Emergency-Services	1538	7.2.3.4	Unsigned32	V			M,P
IMEI-Check-In-VPLMN-Result	1540	5.2.3.35	Unsigned32	V			M,P
NOTE 1: The AVP header bit denoted as "M", indicates whether support of the AVP is required. The AVP header bit denoted as "V", indicates whether the optional Vendor-ID field is present in the AVP header. For further details, see IETF RFC 6733 [58],. NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit.

The following table describes the Diameter AVPs re-used by the STa interface protocol from existing Diameter Applications, including a reference to their respective specifications and when needed, a short description of their use within STa. Other AVPs from existing Diameter Applications, except for the AVPs from Diameter base protocol defined in IETF RFC 6733 [58], do not need to be supported.

Table 5.2.3.1/2: STa re-used Diameter AVPs

Attribute Name	Reference	Comments	M-bit
Accounting-Interim-Interval	IETF RFC 6733 [58]
Auth-Request-Type	IETF RFC 6733 [58]
Calling-Station-Id	IETF RFC 4005 [4]
Subscription-ID	IETF RFC 4006 [20]		Must not set
EAP-Master-Session-Key	IETF RFC 4072 [5]
EAP-Payload	IETF RFC 4072 [5]
RAT-Type	3GPP TS 29.212 [23]
Re-Auth-Request-Type	IETF RFC 6733 [58]
Session-Timeout	IETF RFC 6733 [58]
User-Name	IETF RFC 6733 [58]
Terminal-Information	3GPP TS 29.272 [29]
MIP6-Agent-Info	IETF RFC 5447 [6]
APN-OI-Replacement	3GPP TS 29.272 [29]
Supported-Features	3GPP TS 29.229 [24]
Feature-List-ID	3GPP TS 29.229 [24]	See clause 5.2.3.10
Feature-List	3GPP TS 29.229 [24]	See clause 5.2.3.11
BSSID	3GPP TS 32.299 [30]
Location-Information	IETF RFC 5580 [46]
Location-Data	IETF RFC 5580 [46]
Operator-Name	IETF RFC 5580 [46]
Logical-Access-ID	ETSI TS 283 034 [48]
Local-Time-Zone	3GPP TS 29.272 [29]
PDN-Type	3GPP TS 29.272 [29]
Served-Party-IP-Address	3GPP TS 32.299 [30]
OC-Supported-Features	IETF RFC 7683 [47]	See clause 8.2.3.22
OC-OLR	IETF RFC 7683 [47]	See clause 8.2.3.23
DRMP	IETF RFC 7944 [53]	See clause 8.2.3.25	Must not set
Emergency-Info	3GPP TS 29.272 [29]
Load	IETF RFC 8583 [54]	See clause 8.2.3.26	Must not set
ERP-RK-Request	IETF RFC 6942 [57]		Must not set
Key	IETF RFC 6734 [56]	This is a grouped AVP containing Key-Type, Keying-Material and, optionally, Key-Lifetime.	Must not set
ERP-Realm	IETF RFC 6942 [57]		Must not set
UE-Usage-Type	3GPP TS 29.272 [29]
NOTE 1: The M-bit settings for re-used AVPs override those of the defining specifications that are referenced. Values include: "Must set", "Must not set". If the M-bit setting is blank, then the defining specification applies. NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit.

Only those AVP initially defined in this reference point or AVP with values initially defined in this reference point and for this procedure are described in the following clause.

5.2.3.2 Mobile-Node-Identifier

The Mobile-Node-Identifier AVP (AVP Code 506) is of type UTF8String.

The Mobile-Node-Identifier AVP is returned in an answer message that ends a successful authentication (and possibly an authorization) exchange between the AAA client and the AAA server. The returned Mobile Node Identifier may be used as the PMIPv6 MN-ID or as the MIPv4 MN-NAI or to derive the IMSI to be sent in GTPv2 signalling.

The Mobile-Node-Identifier is defined on IETF RFC 5779 [2].

5.2.3.3 MIP6-Feature-Vector

The MIP6-Feature-Vector AVP (AVP Code 124) is of type Unsigned64 and contains a 64 bit flags field of supported mobile IP capabilities of the non-3GPP access network (when this AVP is used in the request commands) and the mobile IP capabilities the 3GPP AAA Server has authorized (when this AVP is used in the response commands).

The following capabilities are defined for STa interface:

– MIP6_INTEGRATED (0x0000000000000001)
This flag is set by the non-3GPP access network and the 3GPP AAA Server. It means that the Mobile IPv6 integrated scenario bootstrapping functionality is supported.

– PMIP6_SUPPORTED (0x0000010000000000)
When this flag is set by the non-3GPP access network it indicates to the 3GPP AAA Server that it supports PMIPv6.
When this flag is set by the 3GPP AAA Server it indicates to the non-3GPP access network that NBM shall be used.

– ASSIGN_LOCAL_IP (0x0000080000000000)
This flag is set by the 3GPP AAA Server.
When this flag is set by the 3GPP AAA Server it indicates to the non-3GPP access network that the non-3GPP access network shall assign to the user a local IP address (for HBM).

– MIP4_SUPPORTED (0x0000100000000000)
This flag is set by the non-3GPP access network, the PDN GW and the 3GPP AAA Server. When this flag is set by the non-3GPP access network it indicates to the 3GPP AAA Server that it supports MIPv4 FA-CoA mode. When this flag is set by the 3GPP AAA Server it indicates to the non-3GPP access network that MIPv4 FA-CoA mode shall be used. When this flag is set by the PDN GW and 3GPP AAA Server over the S6b interface, it shows that MIPv4 mobility protocol is used on the S2a interface.

– OPTIMIZED_IDLE_MODE_MOBILITY (0x0000200000000000)
This flag is set by the Trusted Non-3GPP access network if the PDN GW information needs to be updated for the case of idle mode mobility from E-UTRAN to HRPD access.

– GTPv2_SUPPORTED (0x0000400000000000)
When this flag is set by the non-3GPP access network it indicates to the 3GPP AAA Server that it supports GTPv2.
When this flag is set by the 3GPP AAA Server it indicates to the non-3GPP access network that NBM shall be used.

5.2.3.4 QoS Capability

This AVP is FFS

5.2.3.5 Service-Selection

The Service-Selection AVP is of type of UTF8String. This AVP contains an APN Network Identifier (i.e., an APN without the Operator Identifier), and it shall consist of one or more labels according to DNS naming conventions (IETF RFC 1035 [35]) describing the access point to the packet data network.

The contents of the Service-Selection AVP shall be formatted as a character string composed of one or more labels separated by dots (".").

The Service-Selection AVP is defined in IETF RFC 5778 [11].

5.2.3.6 RAT-Type

The RAT-Type AVP (AVP code 1032) is of type Enumerated and is used to identify the radio access technology that is serving the UE. It follows the specification described in TS 29.212 [23].

5.2.3.7 ANID

The ANID AVP is of type UTF8String; this AVP contains the Access Network Identity; see 3GPP TS 24.302 [26] for defined values.

5.2.3.8 AMBR

Please refer to 3GPP TS 29.272 [29] for the encoding of this AVP.

5.2.3.9 AN-Trusted

The AN-Trusted AVP (AVP Code 1503) is of type Enumerated.

The AN-Trusted AVP sent from the 3GPP AAA Server to the Non-3GPP access network conveys the decision about the access network being trusted or untrusted by the HPLMN.

The following values are defined:

TRUSTED (0)

This value is used when the non-3GPP access network is to be handled as trusted.

UNTRUSTED (1)

This value is used when the non-3GPP access network is to be handled as untrusted.

5.2.3.10 Feature-List-ID AVP

The syntax of this AVP is defined in 3GPP TS 29.229 [24]. For this release, the Feature-List-ID AVP value shall be set to 1 for the STa/SWa application.

5.2.3.11 Feature-List AVP

The syntax of this AVP is defined in 3GPP TS 29.229 [24]. A null value indicates that there is no feature used by the STa/SWa application.

NOTE: There are no STa/SWa features defined for this release.

5.2.3.12 MIP-FA-RK

The MIP-FA-RK AVP is of type OctetString; this AVP contains the FA-RK used to calculate the security parameters needed for the MN-FA authentication extension as defined by 3GPP TS 33.402 [19].

5.2.3.13 MIP-FA-RK-SPI

The MIP-FA-RK-SPI AVP is of type Unsigned32; this AVP contains the security index used in identifying the security context for the FA-RK as defined by 3GPP TS 33.402 [19].

5.2.3.14 Full-Network-Name

The Full-Network-Name AVP is of type OctetString; this AVP shall contain the Full Network Name and be encoded as the Full name value field of the AT_FULL_NAME_FOR_NETWORK attribute specified in clause 8.2.5.1 of 3GPP TS 24.302 [26].

5.2.3.15 Short-Network-Name

The Short-Network-Name AVP is of type OctetString; this AVP shall contain the Short Network Name and be encoded as the Short name value field of the AT_SHORT_NAME_FOR_NETWORK attribute specified in clause 8.2.5.2 of 3GPP TS 24.302 [26].

5.2.3.16 Void

5.2.3.17 Void

5.2.3.18 WLAN-Identifier

The WLAN-Identifier AVP is of type Grouped. It contains the type and value of an IEEE 802.11 identifier of a Trusted WLAN.

AVP Format:

WLAN-Identifier ::= < AVP Header: 1509 10415 >

[SSID ]

[HESSID ]

*[ AVP ]

5.2.3.19 Transport-Access-Type

The Transport-Acess-Type AVP (AVP code 1519) is of type Enumerated and is used to identify the transport access technology that is serving the UE.

The following values are defined:

BBF (0)

This value shall be used to indicate a BBF transport access network.

5.2.3.20 DER-Flags

The DER-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 5.2.3.20/1:

Table 5.2.3.20/1: DER-Flags

Bit	Name	Description
0	NSWO-Capability-Indication	This bit, when set, indicates to the 3GPP AAA proxy/server that the TWAN supports non-seamless WLAN offload service (see clause 16 of 3GPP TS 23.402 [3]).
1	TWAN-S2a-Connectivity-Indicator	This bit is only applicable to the TWAN authentication and authorization procedure, when authorizing the SCM for EPC access. When set, it indicates to the 3GPP AAA Server that the TWAN has completed the necessary S2a network connectivity actions, and the 3GPP AAA Sever can finalize the EAP conversation by sending a final EAP ‘Success’ or ‘Failure’ response to the TWAN.
2	IMEI-Check-Required-In-VPLMN	This bit is only applicable to the TWAN authentication and authorization procedure, when the UE and the network support Mobile Equipment Identity signalling over trusted WLAN. When set, it indicates to the 3GPP AAA Server that the 3GPP AAA Server shall retrieve the IMEI(SV) from the UE and return it to the VPLMN with the IMEI-Check-Request-In-VPLMN bit set in the DEA-Flags.
3	IMEI-Check-Request-In-VPLMN	This bit is only applicable to the TWAN authentication and authorization procedure, when the UE and the network support Mobile Equipment Identity signalling over trusted WLAN. When set, it indicates that the 3GPP AAA Proxy shall perform the IMEI(SV) check in the VPLMN and send the IMEI check result to the 3GPP AAA Server.
4	Emergency-Capability-Indication	This bit, when set, indicates to the 3GPP AAA Server that the TWAN supports IMS emergency sessions (see clause 4.5.7 of 3GPP TS 23.402 [3]).
5	ERP-Support-Indication	This bit, when set, indicates to the 3GPP AAA proxy/server that the non-3GPP access network supports EAP extensions for the EAP Re-authentication Protocol (ERP).
6	ERP-Re-Authentication	This bit, when set, indicates to the 3GPP AAA proxy/server that the authentication request is sent for EAP re-authentication based on ERP.
NOTE: Bits not defined in this table shall be cleared by the sender and discarded by the receiver of the command.

5.2.3.21 DEA-Flags

The DEA-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 5.2.3.21/1:

Table 5.2.3.21/1: DEA-Flags

Bit	Name	Description
0	NSWO-Authorization	This bit, when set, indicates to the TWAN that the non-seamless WLAN offload service is authorized (see clause 16 of 3GPP TS 23.402 [3]).
1	TWAN-S2a-Connectivity-Indicator	This bit is only applicable to the TWAN authentication and authorization procedure, when authorizing the SCM for EPC access; when set, it indicates to the TWAN that the EAP-AKA’ authentication has been successful (i.e., the 3GPP AAA Server has checked the validity of the challenge response sent by the UE), and the network connectivity set up may proceed at the TWAN.
2	IMEI-Check-Request-In-VPLMN	This bit is only applicable to the TWAN authentication and authorization procedure, when the UE and the network support Mobile Equipment Identity signalling over trusted WLAN. When set, it indicates that the VPLMN shall perform the IMEI check and return the outcomes to the 3GPP AAA Server.
NOTE: Bits not defined in this table shall be cleared by the sender and discarded by the recever of the command.

5.2.3.22 SSID

The SSID AVP is of type UTF8String and it shall contain the Service Set Identifier which identifies a specific 802.11 extended service set (see IEEE Std 802.11-2012 [40]). It shall contain a string of 1 to 32 octets.

5.2.3.23 HESSID

The HESSID AVP is of type UTF8String and it shall contain a 6-octet MAC address that identifies the Homogenous Extended Service Set (see IEEE Std 802.11-2012 [40]). It shall be encoded in upper-case ASCII characters with the octet values separated by dash characters. It shall contain a string of 17 octets. Example: "00-10-A4-23-19-C0".

5.2.3.24 Access-Network-Info

The Access-Network-Info AVP is of type Grouped.

For a Trusted WLAN, it shall contain the SSID of the WLAN and, unless otherwise determined by the TWAN operator’s policies, it shall contain at least one of the following elements:

– the BSSID,

– the civic address of the access point to which the UE is attached,

– the Logical Access ID (see ETSI ES 283 034 [48]) associated to the access point to which the UE is attached.

It may also contain the name of the TWAN operator (either a PLMN-ID or an operator name in realm format).

For an untrusted WLAN, it shall contain the same information as specified above for a trusted WLAN, where the operator name indicates the WLAN operator name.

AVP Format:

Access-Network-Info ::= < AVP Header: 1526 10415 >

[ SSID ]

[ BSSID ]

[ Location-Information ]

[ Location-Data ]

[ Operator-Name ]

[ Logical-Access-ID ]

*[ AVP ]

The Location-Data and Location-Information AVPs are defined in IETF RFC 5580 [46]; the content of Location-Information shall indicate that the encoding follows a civic location profile, by setting the "Code" field to 0.

The Operator-Name AVP is defined in IETF RFC 5580 [46]; the first 8 bits contain the Namespace ID field, whose values are managed by IANA, and are encoded as a single ASCII character. Only values "1" (Realm) and "2" (E212, containing MCC and MNC values) shall be used in this specification.

5.2.3.25 TWAN-Connection-Mode

The TWAN-Connection-Mode AVP (AVP Code 1527) is of type Unsigned32 and it shall contain a 32 bit flags field which is used to indicate the connection modes supported by the TWAN (when this AVP is used in the request commands) and the selected TWAN connection mode the 3GPP AAA Server has authorized (when this AVP is used in the response commands).

Table 5.2.3.25/1: TWAN-Connection-Mode

Bit	Name	Description
0	TSC-MODE	This bit, when set by the TWAN, indicates to the 3GPP AAA Server that the TWAN supports the TSCM.
1	SC-MODE	This bit, when set by the TWAN, indicates to the 3GPP AAA Server that the TWAN supports the SCM. This bit, when set by the 3GPP AAA Server, indicates to the TWAN that the SCM shall be used.
2	MC-MODE	This bit, when set by the TWAN, indicates to the 3GPP AAA Server that the TWAN supports the MCM. This bit, when set by the 3GPP AAA Server, indicates to the TWAN that the MCM shall be used.
NOTE: Bits not defined in this table shall be cleared by the sender and discarded by the receiver of the command.

5.2.3.26 TWAN-Connectivity-Parameters

The TWAN-Connectivity-Parameters AVP is of type Grouped.

AVP Format:

TWAN-Connectivity-Parameters ::= < AVP Header: 1528 10415 >

[ Connectivity-Flags ]

[ Service-Selection ]

[ PDN-Type ]

* 2 [ Served-Party-IP-Address ]

[ TWAN-PCO ]

[ TWAG-UP-Address ]

[ TWAN-S2a-Failure-Cause ]

[ SM-Back-Off-Timer ]

*[ AVP ]

The Service-Selection AVP indicates the APN requested by the UE (requested connectivity parameters) or the APN selected by the TWAN (provided connectivity parameters). It shall contain both the network identifier part and the operator identifier part of the Access Point Name.

The PDN-Type AVP indicates the PDN type requested by the UE (requested connectivity parameters) or the PDN type allocated by the network (provided connectivity parameter). It may be set to IPv4, IPv6 or IPv4v6.

The UE’s Served-Party-IP-Address AVP may be present 0, 1 or 2 times. These AVPs shall be present if the S2a connection was successfully established, and they shall contain either of:

– an IPv4 address, or

– an IPv6 interface identifier, or

– both, an IPv4 address and an IPv6 interface identifier.

For the IPv6 interface identifier, the higher 64 bits of the address shall be set to zero.

The TWAN-S2a-Failure-Cause AVP may be present to indicate the cause of S2a connectivity establishment failure.

The SM-Back-Off-Timer AVP may be present to provide a Session Management back-off timer to be sent to the UE. The exact value of the SM-Back-Off-Timer is operator dependant.

5.2.3.27 Connectivity-Flags

The Connectivity-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 5.2.3.26/1:

Table 5.2.3.26/1: Connectivity-Flags

Bit

Name

Description

Initial-Attach-Indicator

This bit may be set by the 3GPP AAA Server.

This bit, when set, indicates that a UE performs the Initial Attach procedure from non-3GPP access network. When not set, it indicates that a UE performs the Handover procedure.

NOTE: Bits not defined in this table shall be cleared by the sender and discarded by the receiver of the command.

5.2.3.28 TWAN-PCO

The TWAN-PCO AVP is of type OctetString and shall contain the Protocol Configuration Options for the UE.

5.2.3.29 TWAG-CP-Address

The TWAG-CP-Address AVP is of type Address and shall contain the TWAG control-plane IPv4 and/or IPv6 address that the TWAG supports, to be used for WLCP by the UE if MCM is selected.

5.2.3.30 TWAG-UP-Address

The TWAG-UP-Address AVP is of type UTF8String and shall contain a 6-octet MAC address that identifies the TWAG user-plane MAC address to be used for encapsulating user plane packets between the UE and the TWAN, when SCM is used.

It shall be encoded in upper-case ASCII characters with the octet values separated by dash characters. It shall contain a string of 17 octets. Example: "00-10-A4-23-19-C0".

5.2.3.31 TWAN-S2a-Failure-Cause

The TWAN-S2a-Failure-Cause AVP (AVP Code 1533) is of type Unsigned32 and it shall contain a 32 bit cause value field which is used to indicate the cause of S2a connectivity establishment failure to the 3GPP AAA Server by the TWAN. The description of the TWAN-S2a-Failure-Cause value is specified as in Table 5.2.3.30/1:

Table 5.2.3.30/1: TWAN-S2a-Failure-Cause value description

Cause value (decimal)	Cause Value	Meaning
26	Insufficient resources	This cause is used to indicate that the requested service cannot be provided due to insufficient resources.
27	Unknown APN	This cause is used to indicate that the requested service was rejected because the access point name could not be resolved.
29	User authentication failed	This cause is used to indicate that the requested service was rejected by the external packet data network due to a failed user authentication
30	Request rejected by TWAN or PDN GW	This cause is used to indicate that the requested service or operation was rejected by the TWAN or PDN GW.
31	Request rejected, unspecified	This cause is used to indicate that the requested service or operation was rejected due to unspecified reasons.
32	Service option not supported	This cause is used to indicate that the UE requests a service which is not supported by the PLMN.
33	Requested service option not subscribed	This cause is used to indicate that the UE requests a service option which it has no subscription.
34	Service option temporarily out of order	This cause is used to indicate that the network cannot serve the request because of temporary outage of one or more functions required for supporting the service.
38	Network failure	This cause is used to indicate that the requested service was rejected due to an error situation in the network.
50	PDN type IPv4 only allowed	This value is used to indicate that only PDN type IPv4 is allowed for the requested PDN connectivity.
51	PDN type IPv6 only allowed	This value is used to indicate that only PDN type IPv6 is allowed for the requested PDN connectivity.
54	PDN connection does not exist	This value is used at handover from a 3GPP access network to indicate that the network does not have any information about the requested PDN connection.
113	Multiple accesses to a PDN connection not allowed	This value is used to indicate that the request for the additional access to a PDN connection was rejected by the PDN GW.

5.2.3.32 SM-Back-Off-Timer

The SM-Back-Off-Timer AVP is of type Unsigned32 and it shall contain the session management back-off timer value in seconds. The session management back-off timer is provided to the UE as specified in clause 8.1.4.16 of 3GPP TS 24.302 [26].

5.2.3.33 WLCP-Key

The WLCP-Key AVP (AVP Code 1535) is of type OctetString and it shall contain the WLCP Key used for protecting the WLCP signalling between the UE and the TWAN, as specified in 3GPP TS 33.402 [19].

5.2.3.34 Void

5.2.3.35 IMEI-Check-In-VPLMN-Result

The IMEI-Check-In-VPLMN-Result AVP (AVP Code 1540) is of type Unsigned32 and it shall contain a 32 bit cause value field which is used to indicate the result of the IMEI check performed in the VPLMN. The description of the IMEI-Check-In-VPLMN-Result value is specified as in Table 5.2.3.35/1:

Table 5.2.3.35/1: IMEI-Check-In-VPLMN-Result value description

Cause value

(decimal)

Cause Value

Meaning

Successful

This cause is used to indicate that the IMEI check has been performed successfully in the VPLMN.

Illegal_ME

This cause is used to indicate that the IMEI check has failed in the VPLMN due to an illegal Mobile Equipment.

5.2.4 Session Handling

The Diameter protocol between the non-3GPP access network and the 3GPP AAA Server or 3GPP AAA Proxy, shall always keep the session state, and use the same Session-Id parameter for the lifetime of each Diameter session.

A Diameter session shall identify a given user. In order to indicate that the session state is to be maintained, the Diameter client and server shall not include the Auth-Session-State AVP, either in the request or in the response messages (see IETF RFC 6733 [58]).