S6a Interface Description in HSS

INTERWORK DESCRIPTION

2/155 19-APR 901 0321/5 Uen A

Copyright

© Ericsson España, S.A. 2011.All rights reserved. No part of this document may
be reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to
continued progress in methodology, design, and manufacturing. Ericsson
shall have no liability for any error or damages of any kind resulting from the
use of this document.

Trademark List

Ericsson is the trademark or registered trademark of

Telefonaktiebolaget LM Ericsson.

All other product or service names mentioned in this document are trademarks
of their respective companies.

Abstract

This document is a description of the S6a interface, that is the reference

point between the Home Subscriber Server (HSS) node and the Mobility
Management Entity (MME) node.

S6a interface is an application extension to the Diameter Base protocol. See

Reference [4].

2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 Contents

Contents

1 Introduction 1
1.1 Document Purpose and Scope 1
1.2 Revision Information 1

2 Overview 1

3 S6a Interface 2
3.1 General Procedures 2
3.2 Session Handling 3
3.3 Command-Code Values 3
3.4 Command Descriptions 4

4 Error Handling 20
4.1 Result-Code AVP Values 21
4.2 Experimental-Result AVP Values 21

5 Diameter Base Protocol AVPs 22

6 S6a Application AVPs 22

6.1 3GPP AVPs 23
6.2 IETF AVPs 42

Glossary 45

Reference List 47

2/155 19-APR 901 0321/5 Uen A | 2011-09-30

S6a Interface Description in HSS

2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 Overview

1 Introduction

1.1 Document Purpose and Scope

The document describes the message structures provided by the S6a interface,
as well as the parameters and their data formats.

1.2 Revision Information

Rev. A This document is based on document 2/155 19-APR 901
0321/4 Uen Rev. A.
Changes on the aforementioned document are stated below:
• STN-SR AVP has been added in Subscription-Data AVP
• IMEI and software version AVPs are treated by HSS.
Access Restriction AVP supported values are updated
• MPS-Priority AVP has been added in Subscription-Data
AVP
• Some enhancements regarding AVPs value relation to
licenses.
• Regional-Subscription-Zone-Code AVP introduced.
• Roaming-Restricted-Due-To-Unsupported-Feature AVP
introduced.
• Supported Features AVP extended for Regional Services.
• Terminating Access Domain Selection (TADS) support
impacts added.
• DSR/DSA operations supported by the HSS.

2 Overview

The document describes the S6a Interface with the command codes needed,
the general procedures, the Attribute-Value Pairs (AVPs) in each command

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 1

S6a Interface Description in HSS

and the possible result codes that can be returned. See Reference [1] for more
information.

3 S6a Interface

S6a interface enables transfer of subscriber related data between MME and
HSS as described in Reference [5].

The S6a interface is based on the Diameter Base protocol (see Reference [1])
and offers a subset of procedures described in Reference [6].

Diameter over Stream Control Transmission Protocol (SCTP) is used between

the MME and HSS.

3.1 General Procedures

The following figure shows the information flows required for S6a interface.

Figure 1 S6a Information flows

2 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 S6a Interface

3.2 Session Handling

Among the procedures currently defined for the S6a interface in the Evolved
Packet System, none has a semantic that could be associated with the concept
of a Diameter user session as defined in the Diameter Base Protocol (see
Reference [1]).

The server includes in its requests (responses) the Auth-Session-Stat

e AVP, set to NO_STATE_MAINTAINED for all S6a request messages. As a
consequence, the server does not maintain any state information about this
session and the client does not need to send any session termination request.

Neither the Authorization-Lifetime AVP nor Session-Timeout AVP

are present in the requests or responses.

Consequently, implicitly terminated Diameter sessions are used for every

command issued in this interface.

3.3 Command-Code Values

The following Command Codes are defined in this specification:

Table 1 Command-Code values

Command-Name Source Destination Abbreviation Code
Update-Location-Req MME HSS ULR 316
uest
Update-Location-Ans HSS MME ULA 316
wer
Cancel-Location-Req HSS MME CLR 317
uest
Cancel-Location-Ans MME HSS CLA 317
wer
Authentication-Inform MME HSS AIR 318
ation-Request
Authentication-Inform HSS MME AIA 318
ation-Answer
Insert-Subscriber-Dat HSS MME IDR 319
a-Request
Insert-Subscriber-Dat MME HSS IDA 319
a-Answer
Delete-Subscriber-D HSS MME DSR 320
ata-Request
Delete-Subscriber-D MME HSS DSA 320
ata-Answer

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 3

S6a Interface Description in HSS

Command-Name Source Destination Abbreviation Code

Purge-UE-Request MME HSS PUR 321
Purge-UE-Answer HSS MME PUA 321
Notify-Request MME HSS NOR 323
Notify-Answer HSS MME NOA 323
Reset-Request HSS MME RSR 322
Reset-Answer MME HSS RSA 322

3.4 Command Descriptions

Following there is a description of all the commands of the application,
indicating the AVPs that they include.

The description and format of the Base Protocol is done in Reference [1].

In this document, only the messages and the AVPs included in them, are
described.

Note: In Augmented Backus–Naur Form (ABNF) format '{ }' means

Mandatory, '<' '>' Mandatory with fixed place, '[ ]' means Optional, '*'
means zero or more repetitions of the element and '1*' means 1 or
more repetitions.

3.4.1 Update Location Request (ULR) Command

The Update-Location-Request (ULR), indicated by the Command-Code
field set to 316 and the 'R' bit set in the Command Flags field, is sent by MME
to update location information in the HSS.

The format of this command is the following:

4 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 S6a Interface

<Update-Location-Request>::= < Diameter Header: 316, REQ, PXY,

16777251>
<Session-Id>
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
{ User-Name }
*[ Supported-Features ]
[ Terminal-Information ]
{ ULR-Flags }
{ Visited-PLMN-Id }
[ Homogeneous-Support-of-IMS-Voice-Ove
r-PS-Sessions ]
{ RAT-Type }
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

3.4.2 Update-Location-Answer (ULA) Command

The Update-Location-Answer (ULA), indicated by the Command-Code field
set to 316 and the 'R' bit set to zero in the Command Flags field of the header,
is sent to MME in response to the Update-Location-Request command.

The format of this command is the following:

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 5

S6a Interface Description in HSS

<Update-Location-Answer <Diameter Header: 316, PXY, 16777251>

>::=
<Session-Id>
{ Vendor-Specific-Application-Id }
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Supported-Features ]
[ ULA-Flags ]
[ Subscription-Data ]
*[ AVP ]
*[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

The Subscription-Data and the ULA-Flags AVPs are mandatory in case

of successful results.

The Result-Code AVP may be one of the values defined in the Diameter
Base Protocol (see Reference [1]), but HSS uses the following value in special
situations:

• DIAMETER_UNABLE_TO_COMPLY (5012), if HSS is not able to process

the operation. See Reference [2] .

The Experimental-Result AVP may have the following value:

• DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION (5420), if the user is

unknown or EPS user is barred for all Packet Oriented Services, and MME
does not support this ODB type..

• DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004), if the user is not

allowed to roam in the visited network or due to Operator Determined
Barring.

• DIAMETER_ERROR_FEATURE_UNSUPPORTED (5011), if HSS does not

support all the features indicated in the received Supported-Features AVP
of the incoming request.

6 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 S6a Interface

• DIAMETER_ERROR_RAT_NOT_ALLOWED (5421), if the user access to

E-UTRAN is restricted.

3.4.3 Authentication-Information-Request (AIR) Command

The Authentication-Information-Request (AIR), indicated by the
Command-Code field set to 318 and the 'R' bit set in the Command Flags field,
is sent by MME to request Authentication Information.

The format of this command is the following:

< Authentication-Information-Requ < Diameter Header: 318, REQ, PXY,

est> ::= 16777251>
<Session-Id>
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
{ User-Name }
*[ Supported-Features ]
{ Requested-EUTRAN-Authentication-I
nfo }
{ Visited-PLMN-Id }
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

3.4.4 Authentication-Information-Answer (AIA) Command

The Authentication-Information-Answer (AIA), indicated by
the Command-Code field set to 318 and the 'R' set to zero in the
Command Flags field of the header, is sent to MME in response to
Authentication-Information-Request (AIR) command.

The format of this command is the following:

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 7

S6a Interface Description in HSS

< Authentication-Information-Answe < Diameter Header: 318, PXY,

r> ::= 16777251>
<Session-Id>
{ Vendor-Specific-Application-Id }
[ Result-Code ]
[ Experimental Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Authentication-Info ]
*[ AVP ]
*[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

The Authentication-Info AVP is mandatory in case of successful results.

The Result-Code AVP may be one of the values defined in the Diameter
Base Protocol (see Reference [1]), but HSS uses the following value in special
situations:

• DIAMETER_AUTHORIZATION_REJECTED (5003), when required

authentication data is not defined for this user. See Reference [3] for more
information.

• DIAMETER_UNABLE_TO_COMPLY (5012), if HSS is not able to process

the operation. See Reference [2] .

The Experimental-Result AVP in error cases have the following value:

• DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION (5420), if the user

is unknown.

• DIAMETER_AUTHENTICATION_DATA_UNAVAILABLE (4181), when

authentication data cannot be calculated due to unexpected or unknown
failures. See Reference [3] for more information.

8 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 S6a Interface

3.4.5 Insert-Subscriber-Data-Request (IDR) Command

The Insert-Subscriber-Data-Request (IDR), indicated by the

Command-Code field set to 319 and the 'R' bit set in the Command Flags field
of the header, is sent to MME for updating user data in the MME.

The format of this command is the following:

<Insert-Subscriber-Data- <Diameter Header: 319, REQ, PXY, 16777251>

Request>::=
<Session-Id>
{ Vendor-Specific-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ Destination-Realm }
{ User-Name }
*[ Supported-Features ]
{ Subscription-Data }
[ IDR-Flags ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

The Subscription-Data AVP shall only include ODB data related to the
features supported by the MME to which this request is sent.

The Supported-Features AVP, when present, shall be sent with

the 'M-bit' set and indicating the features needed according to the data
inSubscription-Data AVP.

3.4.6 Insert-Subscriber-Data-Answer (IDA) Command

The Insert-Subscriber-Data-Answer (IDA), indicated by the
Command-Code field set to 319 and the 'R' bit set to zero in the
Command Flags field of the header, is sent by MME in response to the
Insert-Subscriber-Data-Request command.

The format of this command is the following:

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 9

S6a Interface Description in HSS

<Insert-Subscriber-Data- <Diameter Header: 319, PXY, 16777251>

Answer>::=
<Session-Id>
[ Vendor-Specific-Application-Id ]
*[ Supported-Features ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ IMS-Voice-Over-PS-Sessions-Supported ]
[ RAT-Type ]
[ IDA-Flags ]
*[ AVP ]
*[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

The Result-Code AVP may be one of the values defined in the Diameter
Base Protocol (see Reference [1]).

The Experimental-Result AVP in error cases may be one of the following:

• DIAMETER_ERROR_USER_UNKNOWN (5001), if the user is unknown.

• DIAMETER_ERROR_FEATURE_UNSUPPORTED (5011), if the MME does not

support all the features indicated in the IDR request.

3.4.7 Delete-Subscriber-Data-Request (DSR) Command

The Delete-Subscriber-Data-Request (DSR), indicated by the

Command-Code field set to 320 and the 'R' bit set in the Command Flags field
of the header, is sent to MME for updating user data in the MME.

The format of this command is the following:

10 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 S6a Interface

<Delete-Subscriber-Data <Diameter Header: 320, REQ, PXY, 16777251>

-Request>::=
<Session-Id>
[Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ Destination-Realm }
{ User-Name }
*[ Supported-Features ]
{DSR-Flags }
*[ Context-Identifier ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

3.4.8 Delete-Subscriber-Data-Answer (DSA) Command

The Delete-Subscriber-Data-Answer (DSA), indicated by the
Command-Code field set to 320 and the 'R' bit set to zero in the
Command Flags field of the header, is sent by MME in response to the
Delete-Subscriber-Data-Request command.

The format of this command is the following:

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 11

S6a Interface Description in HSS

<Delete-Subscriber-Data- <Diameter Header: 320, PXY, 16777251>

Answer>::=
<Session-Id>
[ Vendor-Specific-Application-Id ]
*[ Supported-Features ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ DSA-Flags ]
*[ AVP ]
*[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

The Result-Code AVP may be one of the values defined in the Diameter
Base Protocol (see Reference [1]).

The Experimental-Result AVP in error cases may be one of the following:

• DIAMETER_ERROR_USER_UNKNOWN (5001), if the user is unknown.

3.4.9 Cancel-Location-Request (CLR) Command

The Cancel-Location-Request (CLR), indicated by the Command-Code
field set to 317 and the 'R' bit set in the Command Flags field, is sent to MME to
delete a subscriber record from the MME.

The format of this command is the following:

12 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 S6a Interface

<Cancel-Location-Request <Diameter Header: 317, REQ, PXY, 16777251>

>::=
<Session-Id>
{ Vendor-Specific-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ Destination-Realm }
{ User-Name }
{ Cancellation-Type }
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

3.4.10 Cancel-Location-Answer (CLA) Command

The Cancel-Location-Answer (CLA), indicated by the Command-Code field
set to 317 and the 'R' bit set to zero in the Command Flags field of the header,
is sent by MME in response to the Cancel-Location-Request command.

The format of this command is the following:

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 13

S6a Interface Description in HSS

<Cancel-Location-Answer>::= <Diameter Header: 317, PXY,

16777251>
<Session-Id>
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Supported-Features ]
*[ AVP ]
*[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

The Result-Code AVP may be one of the values defined in the Diameter
Base Protocol (see Reference [1]).

3.4.11 Purge-UE-Request (PUR) Command

The Purge-UE-Request (PUR), indicated by the Command-Code field set to

321 and the 'R' bit set in the message flags field, is sent by MME to indicate
that the subscriber’s profile has been deleted from the MME.

The format of this command is the following:

14 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 S6a Interface

<Purge-UE-Request>::= <Diameter Header: 321, REQ, PXY, 16777251>

<Session-Id>
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
{ User-Name }
*[ Supported-Features ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

3.4.12 Purge-UE-Answer (PUA) Command

The Purge-UE-Answer (PUA), indicated by the Command-Code field set to
321 and the 'R' bit set to zero in the Command Flags field of the header, is sent
to MME in response to the Purge-UE-Request command.

The format of this command is the following:

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 15

S6a Interface Description in HSS

<Purge-UE-Answer>::= <Diameter Header: 321, PXY,

16777251>
<Session-Id>
{ Vendor-Specific-Application-Id }
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ PUA-Flags ]
*[ AVP ]
*[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

The PUA-Flags AVP is mandatory in case of successful results.

The Result-Code AVP may be one of the values defined in the Diameter
Base Protocol (see Reference [1]), but HSS uses the following value in special
situations:

• DIAMETER_UNABLE_TO_COMPLY (5012), if HSS is not able to process

the operation. See Reference [2].

The Experimental-Result AVP in error cases may have the following value:

• DIAMETER_ERROR_USER_UNKNOWN (5001), if the user is unknown.

3.4.13 Notify-Request (NOR) Command

The Notify-Request (NOR), indicated by the Command-Code field set to

323 and the 'R' bit set in the message flags field, is sent by MME to notify
different events to HSS .The following indications are treated by HSS: a) the
need to inform HLR that a user has moved to LTE and the MME has not
changed so a cancel location should be sent to SGSN; b) assignment/change
of a dynamically allocated PDN GW for an APN. It can also be used by MME to
notify of other events, but they are not treated by HSS.

The format of this command is the following:

16 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 S6a Interface

<Notify-Request>::= <Diameter Header: 323, REQ, PXY, 16777251>

<Session-Id>
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
{ User-Name }
*[ Supported-Features ]
[ NOR-Flags ]
[ Terminal-Information ]
[ MIP6-Agent-Info ]
[ Visited-Network-Identifier]
[ Context-Identifier ]
[Service-Selection]
[ Alert-Reason ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

3.4.14 Notify-Answer (NOA) Command

The Notify-Answer (NOA), indicated by the Command-Code field set to 323
and the 'R' bit set to zero in the Command Flags field of the header, is sent to
MME in response to the Notify-Request command.

The format of this command is the following:

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 17

S6a Interface Description in HSS

<Notify-Answer>::= <Diameter Header: 323, PXY,

16777251>
<Session-Id>
{ Vendor-Specific-Application-Id }
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ AVP ]
*[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

The Result-Code AVP may be one of the values defined in the Diameter
Base Protocol (see Reference [1]), but HSS uses the following value in special
situations:

• DIAMETER_UNABLE_TO_COMPLY (5012), when the received MME address

is different from the stored one. It is also used if HSS is not able to process
the operation. See Reference [2] .

The Experimental-Result AVP in error cases may have the following value:

• DIAMETER_ERROR_USER_UNKNOWN (5001), if the user is unknown.

3.4.15 Reset-Request (RSR) Command

The Reset-Request (RSR), indicated by the Command-Code field set to 322
and the 'R' bit set in the Command Flags field, is sent to MME to indicate that
the HSS may have lost current MME location data for some of its subscribers.

The format of this command is the following:

18 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 S6a Interface

<Reset-Request>::= <Diameter Header: 322, REQ, PXY, 16777251>

<Session-Id>
{ Vendor-Specific-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ Destination-Realm }
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

3.4.16 Reset-Answer (RSA) Command

The Reset-Answer (RSA), indicated by the Command-Code field set to 322

and the 'R' bit set to zero in the Command Flags field of the header, is sent by
MME in response to the Reset-Request command.

The format of this command is the following:

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 19

S6a Interface Description in HSS

<Reset-Answer>::= <Diameter Header: 322, PXY,

16777251>
<Session-Id>
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Supported-Features ]
*[ AVP ]
*[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

The Result-Code AVP may be one of the values defined in the Diameter
Base Protocol (see Reference [1]).

4 Error Handling

There are two types of errors as in Diameter: Protocol and application errors.

Result-Code AVP is focused on Diameter protocol results and

Experimental-Result AVP is focused on specific application ones.

Both Result-Code and Experimental-Result AVPs are used to report

either failures or success operations.

All Diameter answer messages defined in vendor-specific applications must

include either the Result-Code or the Experimental-Result AVP, but
only one of them may be present.

20 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 Error Handling

4.1 Result-Code AVP Values

The Result-Code AVP (AVP value 268) is of type Unsigned32 and indicates
whether a particular request was completed successfully or an error occurred.

All Result-Code AVP values supported by this implementation are described

in Reference [1].

4.2 Experimental-Result AVP Values

This section describes additional error codes(experimental results) apart from
the ones described in the Diameter Base Protocol (see Reference [4]) that must
be supported by all Diameter implementations conforming to this specification.

The Experimental-Result AVP (AVP Code 297) is of type Grouped,

and indicates whether a particular vendor-specific request was completed
successfully or an error occurred. Its Data field has the following ABNF
grammar:

Experimental <AVP Header: 297>

Result::=
{ Vendor-Id }
{ Experimental-Result-Code }

The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains
the Internet Assigned Numbers Authority (IANA) “SMI Network Management
Private Enterprise Codes” value assigned to the vendor of the Diameter device.
In this case, the value assigned by IANA is 10415.

The Experimental-Result-Code AVP values follow the logic given for

Result-Code AVP:

• 2xxx (Success)

• 4xxx (Transient Failures)

• 5xxx (Permanent Failures)

Success category result codes are used to inform a peer that a request has
been successfully completed.

Transient failures result codes are used to inform a peer that the request could
not be satisfied at the time it was received, but may be able to satisfy the
request in the future.

Permanent failures are used to inform the peer that the request failed, and
should not be attempted again.

A Diameter peer implementing this version of the S6a Application can return
the following experimental results:

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 21

S6a Interface Description in HSS

Table 2 Experimental Results

Experimental Result Value Command
DIAMETER_AUTHENTICATION_DA 4181 AIA
TA_UNAVAILABLE
DIAMETER_ERROR_USER_UNKNOW 5001 IDA, PUA
N
DIAMETER_ERROR_ROAMING_NOT 5004 ULA
_ALLOWED
DIAMETER_ERROR_FEATURE_UNS 5011 IDA, ULA
UPPORTED
DIAMETER_ERROR_UNKNOWN_EPS 5420 ULA, AIA
_SUBSCRIPTION
DIAMETER_ERROR_RAT_NOT_ALL 5421 ULA
OWED

5 Diameter Base Protocol AVPs

Diameter Base Protocol AVPs that are included in the S6a messages, are
described in Reference [1]. Diameter messages can also be found in RFC 3588.

There are some particularities for this interface in the following AVPs, described
in Reference [1]:

• User-Name AVP. It contains the permanent identity of the user, that is, the
International Mobile Subscriber Identity (IMSI).

• Auth-Application-Id AVP for S6a application, assigned by IANA is

16777251.

6 S6a Application AVPs

The following table describes the AVPs defined in the S6a application, their
AVP Code values, types and possible flag values.

22 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 S6a Application AVPs

If the <M> flag in the incoming AVP is set but the AVP is not in the HSS
dictionary, the message is rejected.

<M> flag is only relevant in these tables when the given AVP is sent from
the HSS. For the Incoming AVPs the specifications of the <M> flag are not
considered.

The AVP header bit denoted as <V>, indicates whether the Vendor-ID field is
present in the AVP header. See Reference [1] for more information.

6.1 3GPP AVPs

The following table describes the 3rd Generation Partnership Project (3GPP)
AVPs defined in the S6a application, their AVP Code values, types and possible
AVP flag values.

3GPP AVPs have Vendor-ID = 10415.

Table 3 3GPP AVPs

Attribute Name AVP Value Type Must May Should Must
Code not not
3GPP-Charging-C 13 UTF8String M,V
haracteristics
3GPP2-MEID 1471 OctetString M, V
Access-Restriction 1426 Unsigned32 M, V
-Data
Alert-Reason 1434 Enumerated M, V
All-APN-Configura 1428 Enumerated M,V
tions-Included-Indi
cator
Allocation-Retentio 1034 Grouped M,V
n-Priority
AMBR 1435 Grouped M,V
APN-Configuration 1430 Grouped M,V
APN-Configuration 1429 Grouped M, V
-Profile
APN-OI-Replacem 1427 UTF8String M, V
ent
Authentication-Info 1413 Grouped M, V
AUTN 1449 OctetString M, V
Cancellation-Type 1420 Enumerated M,V
Context-Identifier 1423 Unsigned32 M,V

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 23

S6a Interface Description in HSS

Attribute Name AVP Value Type Must May Should Must

Code not not
DSA-Flags 1422 Unsigned32 M, V
DSR-Flags 1421 Unsigned32 M, V
EPS-Subscribed-Q 1431 Grouped M,V
oS-Profile
E-UTRAN-Vector 1414 Grouped M, V
Feature-List-ID 629 Unsigned32 V M
Feature-List 630 Unsigned32 V M
[Homogeneous-Su 1493 Enumerated V M
pport-of-IMS-Voice
-Over-PS-Session
s]
IDA-Flags 1441 Unsigned32 M, V
IDR-Flags 1490 Unsigned32 M, V
IMEI 1402 UTF8String M, V
IMS-Voice-Over-P 1492 Enumerated V M
S-Sessions-Suppo
rted
Immediate-Respon 1412 Unsigned32 M,V
se-Preferred
Item-Number 1419 Unsigned32 M, V
KASME 1450 OctetString M, V
Max-Requested-B 515 Unsigned32 M,V
andwidth-DL
Max-Requested-B 516 Unsigned32 M,V
andwidth-UL
MPS-Priority 1616 Unsigned32 V M
MSISDN 701 OctetString M,V
NOR-Flags 1443 Unsigned32 M, V
Number-Of-Reque 1410 Unsigned32 M, V
sted-Vectors
Operator-Determin 1425 Unsigned32 M, V
ed-Barring
PDN-GW-Allocatio 1438 Enumerated M,V
n-Type
PDN-Type 1456 Enumerated M,V
Priority-Level 1046 Unsigned32 M,V

24 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 S6a Application AVPs

Attribute Name AVP Value Type Must May Should Must

Code not not
PUA-Flags 1442 Unsigned32 M,V
QoS-Class-Identifi 1028 Enumerated M,V
er
RAND 1447 OctetString M, V
RAT-Frequency-S 1440 Unsigned32 M, V
election-Priority-ID
RAT-Type 1032 Enumerated M, V
Regional-Subscript 1446 OctectString M,V
ion-Zone-Code
Requested-EUTR 1408 Grouped M,V
AN-Authentication
-Info
Re-Synchronizatio 1411 OctetString M,V
n-Info
Roaming-Restricte 1457 Enumerated M,V
d-Due-To-Unsupp
orted-Feature
Served-Party-IP-A 848 Address M,V
ddress
Software-Version 1403 UTF8String M,V
Specific-APN-Info 1472 Grouped M,V
STN-SR 1433 OctectString M,V
Subscriber-Status 1424 Enumerated M,V
Subscription-Data 1400 Grouped M,V
Supported-Feature 628 Grouped V M
s
Terminal-Informati 1401 Grouped M,V
on
ULA-Flags 1406 Unsigned32 M,V
ULR-Flags 1405 Unsigned32 M,V
Visited-PLMN-Id 1407 OctetString M,V
VPLMN-Dynamic- 1432 Enumerated M,V
Address-Allowed
XRES 1448 OctetString M,V
Visited-Network-Id 600 OctetString V M
entifier

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 25

S6a Interface Description in HSS

6.1.1 3GPP-Charging-Characteristics AVP

The 3GPP-Charging-Characteristics AVP is of type UTF8String. It

contains the Charging Characteristics according to 3GPP TS 32.299. See
Reference [7].

The structure of the Charging Characteristics value is as follows:

Table 4 Structure of the Charging Characteristics value

8 7 6 5 4 3 2 1
B4 B3 B2 B1 P3 P2 P1 P0 octet 1
B12 B11 B10 B9 B8 B7 B6 B5 octet 2

Bits P0-P3 refer to the Charging Characteristics Profile Index and B1-B12 may
be used by the operator for non-standardised behavior.

Each octet of the Charging Characteristics value is represented via 2 UTF-8

encoded characters in the 3GPP-Charging-Characteristics AVP,
defining its hexadecimal representation.

For example, if P3 and P1 are set to 1, and all the B bits are set to 0, the value
of octet 1 is 10, which hexadecimal representation is 0x0A, and in text form is
"0A". Octet 2 is set to 0, represented as 0x00 in hexadecimal and "00" in text,
so the 3GPP-Charging-Characteristics value in UTF-8 would be "0A00".

6.1.2 3GPP2-MEID AVP

The 3GPP2-MEID AVP is of type OctetString. This AVP contains the Mobile
Equipment Identifier of the user's terminal. See Reference [19].

6.1.3 Access-Restriction-Data AVP

The Access-Restriction-Data AVP is of type Unsigned32 and it shall

contain a bit mask where each bit when set to 1 indicates a restriction. The
meaning of the bits is the following:

AVP bit Meaning

0 UTRAN Not Allowed
1 GERAN Not Allowed
2 GAN Not Allowed
3 I-HSPA-Evolution Not Allowed
4 E-UTRAN Not Allowed
5 HO-To-Non-3GPP-Access Not
Allowed

26 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 S6a Application AVPs

This AVP shall be present within the Subscription-Data AVP sent within a
ULA and/or IDR if at least one of the defined restrictions applies.

Note: AVP bit 5 is always sent to 1 if the Interworking with 3GPP AAA (CXC
901 0989/31) is not activated in HSS.

6.1.4 Alert-Reason AVP

The Alert-Reason AVP is of type Enumerated.

HSS ignores its content.

6.1.5 All-APN-Configurations-Included-Indicator AVP

The All-APN-Configurations-Included-Indicator AVP is of type
Enumerated. The following values are supported:

AVP value Meaning

0 ALL_APN_CONFIGURATIONS_INCLUD
ED
1 MODIFIED/ADDED_APN_CONFIGURATI
ONS_INCLUDED

6.1.6 Allocation-Retention-Priority AVP

The Allocation-Retention-Priority AVP is of type Grouped. It
indicates Priority of Allocation and Retention for the corresponding Access
Point Name (APN) configuration within the Priority-Level AVP. (See
Reference [11]).

The Data field of this AVP has the following ABNF grammar:

Allocation-Retention-Priority ::= <AVP Header: 1034 , Vendor–Id:

10415>
{ Priority-Level }
*[ AVP ]

6.1.7 AMBR AVP

The AMBR AVP is of type Grouped, and contains AVPs that indicate the
aggregate maximum bitrates requested for the uplink and downlink bandwidth.

The Data field of this AVP has the following ABNF grammar:

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 27

S6a Interface Description in HSS

AMBR ::= <AVP Header: 1435 , Vendor–Id:

10415>
{ Max-Requested-Bandwidth-UL }
{ Max-Requested-Bandwidth-DL }
*[ AVP ]

6.1.8 APN-Configuration AVP

The APN-Configuration AVP is of type Grouped. It contains the information

related to APN configuration for a single APN.

The Data field of this AVP has the following ABNF grammar:

APN-Configuration::= <AVP Header: 1430 , Vendor–Id: 10415>

{ Context-Identifier }
*2[ Served-Party-IP-Address ]
{ Service-Selection }
{ PDN-Type }
[ EPS-Subscribed-QoS-Profile ]
[ VPLMN-Dynamic-Address-Allowed ]
[ MIP6-Agent-Info ]
[Visited-Network-Identifier]
[ PDN-GW-Allocation-Type]
[ 3GPP-Charging-Characteristics ]
[ AMBR ]
*[Specific-APN-Info]
*[ AVP ]

If static IP address allocation is used, the APN-Configuration AVP shall

contain either:

• the IPv4 address or the IPv6 address or the IPv6 prefix of the user in one
instance of the Served-Party-IP-Address AVP, if only one of them
is allocated to the user; or,

28 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 S6a Application AVPs

• both the IPv4 address and the IPv6 address/IPv6 prefix of the user in two
instances of the Served-Party-IP-Address AVP, if both are allocated
to the user.

6.1.9 APN-Configuration-Profile AVP

The APN-Configuration-Profile AVP is of type Grouped. It contains
the information related to the user subscribed APN configurations for Evolved
Packet System (EPS) and the context-identifier corresponding to the default
APN configuration.

The Data field of this AVP has the following ABNF grammar:

APN-Configuration <AVP Header: 1429, Vendor–Id: 10415>

-Profile::=
{ Context-Identifier }
{ All-APN-Configurations-Included-Indicator }
1*{ APN-Configuration }
*[ AVP ]

6.1.10 APN-OI-Replacement AVP

The APN-OI-Replacement AVP is of type UTF8String. This AVP Indicates
the domain name to replace the APN Operator Identifier (OI) when constructing
the Packet Data Network (PDN) Gateway (GW) Fully Qualified Domain Name
(FQDN) upon which to perform a Domain Name System (DNS) resolution. The
contents of the APN-OI-Replacement AVP are formatted as a character string
composed of one or more labels separated by dots ("."). See Reference [8].

6.1.11 Authentication-Info AVP

The Authentication-Info AVP is of type Grouped. This AVP contains
Authentication Vectors.

The Data field of this AVP has the following ABNF grammar:

Authentication-Info: <AVP Header: 1413 , Vendor–Id: 10415>

:=
1*{ E-UTRAN-Vector }
*[ AVP ]

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 29

S6a Interface Description in HSS

6.1.12 AUTN AVP

The AUTN AVP is of type OctetString. This AVP contains the Authentication
Token (AUTN). See Reference [10].

6.1.13 Cancellation-Type AVP

The Cancellation-Type AVP is of type Enumerated and indicates the type
of cancellation. The following values are defined:

AVP value Meaning

0 MME_UPDATE_PROCEDURE
2 SUBSCRIPTION_WITHDRAWAL

6.1.14 Context-Identifier AVP

The Context-Identifier AVP is of type Unsigned32 and uniquely identifies
an EPS APN configuration within a user subscription.

6.1.15 DSA-Flags AVP

The Dsa-Flags AVP is of type Unsigned32 and it shall contain a bit mask.

HSS ignores this AVP if received.

6.1.16 DSR-Flags AVP

The Dsr-Flags AVP is of type Unsigned32 and it shall contain a bit mask.
The following values are used by HSS:

Bit Name Description

2 Subscribed Charging This bit, when set, indicates that the Subscribed
Characteristics Charging Characteristics have been deleted from
Withdrawal the subscription data.
3 PDN subscription This bit, when set, indicates that the PDN
contexts Withdrawal subscription contexts whose identifier is included
in the Context-Identifier AVP have been deleted.
4 STN-SR This bit, when set, indicates that the Session
Transfer Number for SRVCC has been removed
from the subscriber data.
10 APN-OI-Replacement This bit, when set, indicates that the UE level
APN-OI-Replacement has been deleted from the
subscriber data.

30 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 S6a Application AVPs

6.1.17 EPS-Subscribed-QoS-Profile AVP

The EPS-Subscribed-QoS-Profile AVP is of type Grouped. It contains

the Quality of Service (QoS) profile information relevant for EPS.

The Data field of this AVP has the following ABNF grammar:

EPS-Subscribed-QoS-Profi <AVP Header: 1431, Vendor–Id: 10415>

le::=
{ QoS-Class-Identifier }
{ Allocation-Retention-Priority }
*[ AVP ]

6.1.18 E-UTRAN-Vector AVP

The E-UTRAN-Vector AVP is of type Grouped. This AVP contains an Evolved
UTRAN (E-UTRAN) Vector.

The Data field of this AVP has the following ABNF grammar:

E-UTRAN-Vector: <AVP Header: 1414, Vendor–Id: 10415>

:=
[ Item-Number ]
{ RAND }
{ XRES }
{ AUTN }
{ KASME }
*[ AVP ]

6.1.19 Feature-List-ID AVP

The Feature-List-ID AVP is of type Unsigned32 and it contains the identity
of a feature list.

6.1.20 Feature-List AVP

The Feature-List AVP is of type Unsigned32 and it contains a bit mask

indicating the supported features of an application.

HSS may support the following features, when the Feature-List-ID AVP
value is 1:

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 31

S6a Interface Description in HSS

AVP bit Meaning

0 ODB-all
1 ODB-HPLMN-APN
2 ODB-VPLMN-APN
(1)
9 RegSub
(2)
26 TADS data retrieval
(1) Depending on a license in HSS (CXC 401 0989/40)
(2) Depending on a license in HSS (CXC 401 0989/37)

6.1.21 Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions AVP

The Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions AVP is
of type Enumerated and it indicates whether IMS Voice over PS Sessions is
supported homogeneously in all TAs (Tracking Areas) in the MME.

The following values are supported:

AVP value Meaning

0 NOT_SUPPORTED
1 SUPPORTED

If this AVP is not present in the command, it indicates that there is no

homogeneous support of IMS Voice Over PS Sessions on all the TA of the
MME, or that the homogeneity of this support is unknown to the MME.

Note: This AVP is ignored by the HSS if the Handling of TADS support
License (CXC 401 0989/37 in ESM is not activated.

6.1.22 IDA-Flags AVP

The IDA-Flags AVP is of type Unsigned32 and it contains a bit mask.

HSS ignores its content.

6.1.23 IDR-Flags AVP

The IDR-Flags AVP is of type Unsigned32 and it contains a bit mask. The
meaning of the bits are the following:

AVP bit Meaning

1 TADS Data Request

The rest of the bits are sent with 0 value.

32 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 S6a Application AVPs

Note: This AVP is not sent by HSS if the Handling of TADS support License
(CXC 401 0989/37) in ESM is not activated.

6.1.24 IMEI AVP

The IMEI AVP is of type UTF8String. This AVP contains the International
Mobile Equipment Identity. See Reference [8].

6.1.25 IMS-Voice-Over-PS-Sessions-Supported AVP

The IMS-Voice-Over-PS-Sessions-Supported AVP is of type

Enumerated and it indicates whether IMS Voice over PS Sessions" is supported
by the UE's most recently used TA in the MME.

The following values are supported:

AVP value Meaning

0 NOT_SUPPORTED
1 SUPPORTED

Note: If this AVP is not present in the command, HSS assumes that
IMS-Voice over PS sessions is not supported.

6.1.26 Immediate-Response-Preferred AVP

The Immediate-Response-Preferred AVP type is of type Unsigned32.
It indicates, when the Authentication Vectors (AV) are requested, that at least
one of the AV is requested for immediate use in the MME.

6.1.27 Item-Number AVP

The Item-Number AVP is of type Unsigned32. If more than one
E-UTRAN Vector is included within one Authentication-Info AVP, the
Item-Number AVP is present within each E-UTRAN Vector.

6.1.28 KASME AVP

The KASME AVP is of type OctetString. This AVP contains the Access Security
Management Entity Key (KASME). See Reference [10].

6.1.29 Max-Requested-Bandwidth-DL AVP

The Max-Requested-Bandwidth-DL AVP is of type Unsigned32 and it
indicates the maximum requested bandwidth in bits per second for a downlink
Internet Protocol (IP) flow. The bandwidth contains all the overhead coming

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 33

S6a Interface Description in HSS

from the IP-layer and the layers above, for instance: IP, User Datagram
Protocol (UDP), Real-time Transport Protocol (RTP) and RTP payload.

6.1.30 Max-Requested-Bandwidth-UL AVP

The Max-Requested-Bandwidth-UL AVP is of type Unsigned32, and it
indicates the maximum requested bandwidth in bits per second for an uplink IP
flow. The bandwidth contains all the overhead coming from the IP-layer and the
layers above, for instance: IP, UDP, RTP and RTP payload.

6.1.31 MPS-Priority
The MPS-Priority AVP is of type Unsigned32 and it shall contain a bit mask.
The meaning of the bits is the following one:

AVP bit Meaning

0 MPS-CS-Priority
1 MPS-EPS-Priority

Note: This AVP is not sent by HSS if the Handling of Service Priority License
(CXC 901 0989/39 ) in ESM is not activated.

6.1.32 MSISDN AVP

The MSISDN AVP is of type OctetString.

This AVP contains a Mobile Subscriber ISDN Number (MISDN), in international

number format as described in ITU-T Rec E.164 (Reference [14]), encoded as
a TBCD-string, that is, digits from 0 through 9 are encoded 0000 to 1001; 1111
is used as a filler when there is an odd number of digits; bits 8 to 5 of octet n
encode digit 2n; bits 4 to 1 of octet n encode digit 2(n-1)+1.

6.1.33 NOR-Flags AVP

The NOR-Flags AVP is of type Unsigned32 and it contains a bit mask.

The supported bits in the mask and their meaning is as follows:

AVP bit Meaning

0 Single-Registration-Indication

The rest of the bits are ignored by the HSS.

34 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 S6a Application AVPs

6.1.34 Number-Of-Requested-Vectors AVP

The Number-Of-Requested-Vectors AVP is of type Unsigned32. This AVP

contains the number of AVs the MME is prepared to receive.

6.1.35 Operator-Determined-Barring AVP

The Operator-Determined-Barring AVP is of type Unsigned32 and it
contains a bit mask indicating the services of a subscriber that are barred by
the operator.

The supported bits are the following:

AVP bit Meaning (when set)

0 All Packet Oriented Services Barred
1 Roamer Access to HPLMN-AP Barred
2 Roamer Access to VPLMN-AP Barred

6.1.36 PDN-GW-Allocation-Type

The PDN-GW-Allocation-Type is of type Enumerated. It contains an

indication whether the PDN GW address is statically allocated or dynamically
selected by other nodes. The following values are defined:

AVP value Meaning

0 STATIC
1 DYNAMIC

6.1.37 PDN-Type AVP

The PDN-Type AVP is of type Enumerated and indicates the address type of
Packet Data Network (PDN). The following values are defined:

AVP value Meaning

0 IPv4
1 IPv6
2 IPv4v6
3 IPv4_OR_IPv6

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 35

S6a Interface Description in HSS

6.1.38 Priority-Level AVP

The Priority-Level AVP is of type Unsigned 32. It indicates the priority

of allocation and retention value for the corresponding APN configuration.
Values 1 to 15 are defined, with value 1 as the highest level of priority. (See
Reference [11]).

6.1.39 PUA-Flags AVP

The PUA-Flags AVP is of type Unsigned32 and it contains a bit mask.

HSS makes use of bit 0 of the bit mask, with the following meaning:

AVP value Meaning

0 Do not freeze M-TMSI
1 Freeze M-TMSI

6.1.40 QoS-Class-Identifier AVP

The QoS-Class-Identifier AVP is of type Enumerated, and it identifies

a set of IP Connectivity Access Network (CAN) specific QoS parameters that
define the authorized QoS, excluding the applicable bitrates for the IP-CAN
bearer or service flow.

6.1.41 RAND AVP

The RAND AVP is of type OctetString. This AVP contains the Random challenge
(RAND). See Reference [10].

6.1.42 RAT-Frequency-Selection-Priority-ID AVP

The RAT-Frequency-Selection-Priority-ID AVP is of type
Unsigned32. This AVP contains the Subscriber Profile ID for RAT/Frequency
Priority. See Reference [5] and Reference [18].

6.1.43 RAT-Type AVP

The RAT-Type AVP is of type Enumerated and is used to identify the Radio
Access Technology (RAT) that is serving the User Equipment (UE). See
Reference [11] for the defined values.

The following value is supported:

36 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 S6a Application AVPs

AVP value Meaning

1004 E-UTRAN

6.1.44 Regional-Subscription-Zone-Code
The Regional-Subscription-Zone-Code AVP is of type OctectString. A Zone
Code has a fixed length of two octets, with any value between 0-FFFF in
hexadecimal representation.

Note: This AVP cannot be sent by HSS if the Regional Services License (CXC
901 0989/40 ) in ESM is not activated.

6.1.45 Requested-EUTRAN-Authentication-Info AVP

The Requested-EUTRAN-Authentication-Info AVP is the type of

Grouped. It contains the information related to the to authentication requests.

If Number-Of-Requested-Vectors AVP is not present, one AV is returned

by the HSS.

The Data field of the Requested-EUTRAN-Authentication-Info AVP has

the following ABNF grammar:

Requested-EUTRAN-Authentication-I < AVP Header: 1408, Vendor–Id:

nfo ::= 10415>
[ Number-Of-Requested-Vectors ]
[ Immediate-Response-Preferred ]
[ Re-Synchronization-Info ]
*[ AVP ]

6.1.46 Re-Synchronization-Info AVP

The Re-Synchronization-Info AVP is of type OctetString. It contains the
concatenation of RAND and the Authentication Token for re-synchronization
(AUTS).

6.1.47 Roaming-Restricted-Due-To-Unsupported-Feature AVP

The Roaming-Restricted-Due-To-Unsupported-Feature AVP is of type
Enumerated and indicates that roaming is restricted due to unsupported
feature. The following value is defined:

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 37

S6a Interface Description in HSS

AVP value Meaning

0 Roaming-Restricted-Due-To-Unsupp
orted-Feature

Note: This AVP cannot be sent by HSS if the Regional Services License
(CXC 901 0989/40) in ESM is not activated.

6.1.48 Served-Party-IP-Address
The Served-Party-IP-Address AVP is of type Address. It contains the
IPv4 address, the IPv6 address or the IPv6 prefix of the user, if static IP
address allocation is used.

For the IPv6 prefix, the lower 64 bits of the address shall be set to zero.

6.1.49 Software-Version AVP

The Software-Version AVP is of type UTF8String. This AVP contains

the Software Version of the International Mobile Equipment Identity. See
Reference [8].

6.1.50 Specific-APN-Info AVP

The Specific-APN-Info AVP is of type Grouped. It shall only be present in

the APN configuration when the APN is a wild card APN. It shall contain the
APN which is not present in the subscription context but the UE is authorized
to connect to and the identity of the registered PDN-GW and optionally the
PLMN Id of the PDN GW.

Specific-APN-Info::= < AVP Header : 1472, Vendor Id: 10415 >

{Service-Selection}
[MIP6-Agent-Info]
[Visited-Network-Identifier]
*[AVP]

6.1.51 STN-SR AVP

The STN-SR AVP is of type OctectString and shall contain the Session Transfer
Number for SRVCC in international number format as described in ITU-T
Rec E.164 (Reference [14]), encoded as a TBCD-string, that is, digits from 0
through 9 are encoded 0000 to 1001; 1111 is used as a filler when there is an
odd number of digits; bits 8 to 5 of octet n encode digit 2n; bits 4 to 1 of octet n
encode digit 2(n-1)+1.

38 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 S6a Application AVPs

Note: This AVP is not sent by HSS if the Single Radio VCC Support in ESM
license (CXC 901 0989/36) is not activated.

6.1.52 Subscriber-Status AVP

The Subscriber-Status AVP is of type Enumerated. The following values
are supported:

AVP value Meaning

0 SERVICE_GRANTED
1 OPERATOR_DETERMINED_BARR
ING

6.1.53 Subscription-Data AVP

The Subscription-Data AVP is of type Grouped. It contains the information
related to the user profile relevant for EPS.

The Data field of this AVP has the following ABNF grammar:

Subscription-Data::= <AVP Header: 1400, Vendor–Id: 10415>

[ MSISDN ]
[STN-SR]
[ Subscriber-Status ]
[ Operator-Determined-Barring ]
[ APN-OI-Replacement ]
[ 3GPP-Charging-Characteristics ]
[ AMBR ]
[ APN-Configuration-Profile ]
[ RAT-Frequency-Selection-Priority-ID ]
[ Access-Restriction-Data ]
*10[ Regional-Subscription-Zone-Code]
[MPS-Priority]
[Roaming-Restricted-Due-To-Unsupported-Feature]
*[ AVP ]

If the Subscriber-Status AVP value is set to OPERATOR_DETERMINED_

BARRING, AVP Operator-Determined-Barring shall be present.

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 39

S6a Interface Description in HSS

Access-Restriction-Data AVP shall be present within the

Subscription-Data AVP if at least one of the defined restrictions applies.

6.1.54 Supported-Features AVP

The Supported-Features AVP is of type Grouped.

If this AVP is present it may inform the destination host about the features that
the origin host supports. The Feature-List AVP contains a list of supported
features of the origin host.

The Vendor-Id AVP and the Feature-List AVP together identify which
feature list is carried in the Supported-Features AVP.

Where a Supported-Features AVP is used to identify features that have

been defined by 3GPP, the Vendor-Id AVP contains the vendor ID of 3GPP.
Vendors may define proprietary features, but it is strongly recommended that
the possibility is used only as the last resort.

Where the Supported-Features AVP is used to identify features that have

been defined by a vendor other than 3GPP, it contains the vendor ID of the
specific vendor in question. If there are multiple feature lists defined by the
same vendor, the Feature-List-ID AVP differentiates those lists from one
another.

The destination host uses the value of the Feature-List-ID AVP to identify
the feature list.

Its Data field has the following ABNF grammar:

Supported-Features::= <AVP Header: 628, Vendor–Id: 10415>

{ Vendor-Id }
{ Feature-List-ID }
{ Feature-List }
*[ AVP ]

6.1.55 Terminal-Information AVP

The Terminal-Information AVP is of type Grouped. This AVP contains
the information about the user’s terminal.

The Data field of this AVP has the following ABNF grammar:

40 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 S6a Application AVPs

Terminal-Information::= <AVP Header: 1401 , Vendor–Id: 10415>

[ IMEI ]
[ 3GPP2-MEID ]
[ Software-Version ]
*[ AVP ]

HSS ignores 3GPP2-MEID AVP.

6.1.56 ULA-Flags AVP

The ULA-Flags AVP is of type Unsigned32 and it contains a bit mask.

HSS always sends ULA-Flags AVP set to 1.

6.1.57 ULR-Flags AVP

The ULR-Flags AVP is of type Unsigned32 and it contains a bit mask.

The supported bits in the mask and their meaning is as follows:

AVP bit Meaning

0 Single-Registration-Indication
1 S6a/S6d-Indicator
2 Skip Subscriber Data
5 Initial-Attach-Indicator

Only the value 1 is supported for bit 1, indicating that the ULR message is sent
on the S6a interface.

Any bits other than the ones stated above are ignored by the HSS.

6.1.58 Visited-Network-Identifier
The Visited-Network-Identifier AVP defined in Reference [21] is of
type OctetString. It contains the identity of the network where the PDN-GW was
allocated, in the case of dynamic PDN-GW assignment.

The AVP shall be encoded as: mnc<MNC>.mcc<MCC>.3gppnetwork.org

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 41

S6a Interface Description in HSS

6.1.59 Visited-PLMN-Id AVP

The Visited-PLMN-Id AVP is the type of OctetString. It contains the

concatenation of Mobile Country Code (MCC) and Mobile Network Code
(MNC) of the Public Land Mobile Network (PLMN) where the user is located.
See Reference [8].

The content of this AVP is encoded as an octet string with the following
structure:

Table 5 Encoding format for Visited-PLMN-Id AVP

8 7 6 5 4 3 2 1
MCC digit 2 MCC digit 1 octet 1
MNC digit 3 MCC digit 3 octet 2
MNC digit 2 MNC digit 1 octet 3

6.1.60 VPLMN-Dynamic-Address-Allowed AVP

The VPLMN-Dynamic-Address-Allowed AVP is of type Enumerated. It
indicates whether the UE is allowed to use a dynamic address allocated in the
Visited PLMN (VPLMN). If this AVP is not present, this means that the UE is
not allowed to use this kind of address. The following values are defined:

AVP value Meaning

0 NOT ALLOWED
1 ALLOWED

6.1.61 XRES AVP

The XRES AVP is of type OctetString. This AVP contains the Expected
Response (XRES). See Reference [10].

6.2 IETF AVPs

The following table describes the IETF AVPs defined in the S6a application,
their AVP Code values, types and possible flag values.

Table 6 IETF AVPs

Attribute Name AVP Value Must May Should Must
Code Type not not
MIP-Home-Age 334 Address M V
nt-Address

42 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 S6a Application AVPs

Attribute Name AVP Value Must May Should Must

Code Type not not
MIP-Home-Age 348 Grouped M V
nt-Host
MIP6-Agent-Info 486 Grouped M V
MIP6-Home-Lin 125 OctetString M V
k-Prefix
Service-Selectio 493 UTF8Stri M V
n ng

6.2.1 MIP-Home-Agent-Address AVP

The MIP-Home-Agent-Address AVP is of type Address defined in Reference

[22]. This AVP shall contain either IPv4 or IPv6 address of the PDN GW, and
this IP address shall be used as the PDN GW IP address.

6.2.2 MIP-Home-Agent-Host AVP

The MIP-Home-Agent-Host AVP is of type Grouped defined in Reference

[22]. This AVP shall contain the FQDN of the Static PDN GW identity, which
shall be used to resolve the PDN GW IP address using the Domain Name
System function.

The Data field of this AVP has the following ABNF grammar:

MIP-Home-Agent-Host:: <AVP Header: 348 >

=
{ Destination-Realm }
{ Destination-Host }
*[ AVP ]

The Destination-Host AVP shall contain the host name of the PDN GW,
formatted as

<"topon" | "topoff">.<single-label-interface-name>.<cano
nical-node-name>

as described in 3GPP TS 29.303, clause 4.3.2,Reference [20]:

The Destination-Realm AVP shall contain the realm name of the PDN
GW, formatted as:

epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

where MNC and MCC values indicate the PLMN where the PDN-GW is located.

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 43

S6a Interface Description in HSS

6.2.3 MIP6-Agent-Info AVP

The MIP6-Agent-Info AVP is of type Grouped defined in Reference [23]. It

shall contain the identity of the PDN GW. The identity of the PDN GW is either
an IP address included in the MIP-Home-Agent-Address AVP or an FQDN
included in the MIP-Home-Agent-Host AVP.

The Data field of this AVP has the following ABNF grammar:

MIP6-Agent-Info::= <AVP Header: 486 >

*2[ MIP-Home-Agent-Address ]
[ MIP-Home-Agent-Host ]
[ MIP6-Home-Link-Prefix ]
*[ AVP ]

If static IP address allocation is used, the MIP6-Agent-Info AVP shall

contain either:

• the IPv4 address or the IPv6 address of the PDN GW in one instance of
the MIP-Home-Agent-Address AVP, if only one of them is allocated
to the PDN GW; or,

• both the IPv4 address and the IPv6 address of the PDN GW in two
instances of the MIP-Home-Agent-Address AVP, if both are allocated
to the PDN GW.

The MIP6-Home-Link-Prefix AVP is not included and is ignored by HSS

when received.

6.2.4 MIP6-Home-Link-Prefix AVP

The MIP6-Home-Link-Prefix AVP is of type OctetString.

This AVP is not used on S6a interface and HSS ignores its content when
received.

6.2.5 Service-Selection AVP

The Service-Selection AVP is of type of UTF8String defined in Reference

[13]. This AVP shall contain either the APN Network Identifier (i.e. an APN
without the Operator Network Identifier), or the wild card value (see Reference
[8], clause 9.1, and Reference [9], clause 2.3.16).

The contents of the Service-Selection AVP shall be formatted as a character

string composed of one or more labels separated by dots (".") or as the wild
card APN, i.e., consisting of only one ASCII label.

44 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 Glossary

Glossary

3GPP GERAN
3rd Generation Partnership Project GSM/EDGE Radio Access Network

3GPP2 GW
3rd Generation Partnership Project 2 Gateway

ABNF HSS
Augmented Backus-Naur Form Home Subscriber Server

AKA IANA
Authentication and Key Agreement Internet Assigned Numbers Authority

AMBR IETF
Aggregate Maximum Bit Rate Internet Engineering Task Force

APN IMSI
Access Point Name International Mobile Subscriber Identity

AUTN IP
Authentication Token Internet Protocol

AUTS ISDN
Authentication Token for re-synchronization Integrated Services Digital Network

AV KASME
Authentication Vector Access Security Management Entity Key

AVP MCC
Attribute-Value Pair Mobile Country Code

CAN MME
Connectivity Access Network Mobility Management Entity

DNS MNC
Domain Name System Mobile Network Code

E-UTRAN MSISDN
Evolved UTRAN Mobile Subscriber ISDN Number

EPC OI
Evolved Packet Core Operator Identifier

EPS PDN
Evolved Packet System Packet Data Network

FQDN PLMN
Fully Qualified Domain Name Public Land Mobile Network

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 45

S6a Interface Description in HSS

QoS
Quality of Service

RAT
Radio Access Technology

RAND
Random challenge

RFC
Request For Comments

RTP
Real-time Transport Protocol

SCTP
Stream Control Transmission Protocol

TA
Tracking Area

TADS
Terminating Access Domain Selection

UDP
User Datagram Protocol

UMTS
Universal Mobile Telecommunications System

UTRAN
UMTS Terrestrial Radio Access Network

UE
User Equipment

UTF
Unicode Transformation Format

VPLMN
Visited PLMN

XRES
Expected Response

46 2/155 19-APR 901 0321/5 Uen A | 2011-09-30

 Reference List

Reference List

Ericsson Documents

[1] Diameter Interface Description in HSS, 5/155 19-CSH 150 0063/6 Uen

[2] Graceful Shutdown in HSS, 5/155 34-CSH 150 0063/6 Uen

[3] EPS Authentication in ESM, 1/155 34-APR 901 0321/4 Uen

Standards

[4] Diameter Base Protocol, RFC 3588

[5] 3rd Generation Partnership Project; Technical Specification Group

Services and System Aspects; General Packet Radio Service (GPRS)
enhancements for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access, 3GPP TS 23.401

[6] 3rd Generation Partnership Project; Technical Specification Group Core

Network and Terminals; Evolved Packet System; MME and SGSN
Related Interfaces Based on Diameter Protocol, 3GPP TS 29.272

[7] 3rd Generation Partnership Project; Technical Specification Group

Service and System Aspects; Telecommunication management; Charging
management; Diameter charging applications, 3GPP TS 32.299

[8] 3rd Generation Partnership Project; Technical Specification Group Core

Network and Terminals; Numbering, addressing and identification, 3GPP
TS 23.003

[9] 3rd Generation Partnership Project; Technical Specification Group Core

Network and Terminals; Organization of subscriber data, 3GPP TS 23.008

[10] 3rd Generation Partnership Project; Technical Specification Group

Services and System Aspects; 3GPP System Architecture Evolution
(SAE); Security architecture, 3GPP TS 33.401

[11] 3rd Generation Partnership Project; Technical Specification Group Core

Network and Terminals; Policy and Charging Control over Gx reference
point, 3GPP TS 29.212

[12] UTF-8, a transformation format of ISO 10646, RFC 2279

[13] Diameter Mobile IPv6: Support for Home Agent to Diameter Server
Interaction, RFC 5778

[14] The International Public Telecommunication Numbering Plan, ITU-T

Recommendation E.164/I.331

2/155 19-APR 901 0321/5 Uen A | 2011-09-30 47

S6a Interface Description in HSS

[15] List of ITU-T Recommendation E.164 assigned country codes,

Complement to ITU-T Recommendation E.164

[16] The international identification plan for mobile terminals and mobile users,
ITU-T Recommendation E.212

[17] List of mobile country or geographical area codes, Complement to ITU-T

Recommendation E.212

[18] 3rd Generation Partnership Project; Technical Specification Group Radio

Access Network; Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) ; S1 Application Protocol (S1AP), 3GPP TS 36.413

[19] Interoperability Specification (IOS) for Evolved High 1 Rate Packet Data
(eHRPD) Radio Access Network 2 Interfaces and Interworking with
Enhanced Universal 3 Terrestrial Radio Access Network (E-UTRAN),
3GPP2 A.S0022

[20] 3rd Generation Partnership Project; Technical Specification Group Core

Network and Terminals; Domain Name System Procedures, 3GPP TS
29.303

[21] Cx and Dx interfaces based on the Diameter protocol; Protocol details,

3GPP TS 29.229

[22] Diameter Mobile IPv4 Application, RFC 4004

[23] Diameter Mobile IPv6: Support for Network Access Server to Diameter
Server Interaction, RFC 5447

48 2/155 19-APR 901 0321/5 Uen A | 2011-09-30