Zh Interface (BSF <--> HSS)

Zh interface is one of the simplest DIAMETER interface with single message, where BSF Bootstrapping Server Function fetches the Authentication Vectors (Credentials) and User's security setting (GUSS) from HSS (Home Subscriber Server) with the help of MAR/MAA
(Multimedia-Auth-Request) message. An application can use SOAP instead of DIAMETER as their base protocol but here we are to discuss Zh keeping DIAMETER in mind. SOAP is not different from DIAMETER, All SOAP element are similar to DIAMETER AVPs.

Zh interface uses Application ID 16777221, and Multimedia-Auth-Request has command code 303.

Before going to depth of Zh it's our request if any question comes in your mind related to Zh interface don't shy to put in comment section, we shall help you.

Bootstrapping Architecture
BSF triggers Multimedia-Auth-Request toward HSS in order to get Authentication Vectors and Guss Profile if any for the user identified by IMPI (IMS private Identity). Message format is as follow

<Multimedia-Auth-Request> ::=<Diameter Header: 303, REQ, PXY, 16777221 >
< Session-Id >
{ Vendor-Specific-Application-Id }
{ Auth-Session-State }       // NO_STATE_MAINTAINED
{ Origin-Host }                     // Host Address of BSF (DIAMETER Identity)
{ Origin-Realm }                 // Realm of BSF (DIAMETER Identity)
{ Destination-Realm }      // Realm of HSS (DIAMETER Identity)
[ Destination-Host ]         // Host Address of the HSS (DIAMETER Identity)
[ User-Name ]                     // IMPI from UE (Private Identity)
[ Public-Identity ]             // IMPU from UE (Public Identity Tel, MSISDN)
[ SIP-Auth-Data-Item ]   // Authentication Scheme, Synchronization Failure
[ GUSS-Timestamp ]        // Diameter Timestamp of GUSS in BSF (This   r
epresents the number of

                                                  seconds since 0h on 1 January 1900)
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

SIP-Auth-Data-Item is a grouped AVP but in Request Message for BSF only two elements are used.

SIP-Auth-Data-Item :: = < AVP Header : 612 10415 >
[ SIP-Item-Number ]
[ SIP-Authentication-Scheme ] ---In Request Message Digest-AKAv1-MD5-2G-GBA or  Digest-AKAv1-MD5
[ SIP-Authenticate ]                       --- In Request Message Concatenation of RAND and 
AUTS to represent re-synchronization.
[ SIP-Authorization ]
[ SIP-Authentication-Context ]
[ Confidentiality-Key ]
[ Integrity-Key ]
[ SIP-Digest-Authenticate ]
* [AVP]

Now after receiving MAR is processed by HSS MAA is formed and sent back with Required Authentication Vectors and GUSS-Profile in XML format. To know complete Vector Generation process visit BSF. MAA follows following format.

< Multimedia-Auth-Answer> ::= < Diameter Header: 303, PXY, 16777221 >
< Session-Id >
{ Vendor-Specific-Application-Id }
[ Result-Code ]
[ Experimental-Result]
{ Auth-Session-State }             // NO_STATE_MAINTAINED
{ Origin-Host }                           // Diameter Host Address of HSS
{ Origin-Realm }                       // Diameter Realm of HSS
[ User-Name ]                            // IMPI (Private Identity)
[ Public-Identity ]                    // IMPU  (Public Identity)
[ SIP-Auth-Data-Item ]          // Authentication Vectors
[ GBA-UserSecSettings ]       // GUSS in XML format.
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

Guss Profile is sent in XML format below image describes element arrangement in XML.
XML Element arrangement for GUSS Profile

XML Elements
Base Tag
It shall contain Private Identity (IMPI) that is received in User-Name AVP of MAR message.
It shall contain time stamp of GUSS, indicating how fresh GUSS profile is. (This represents the number
of seconds since 0h on 1 January 1900)
It shall contain the values of GAA Service Type Code defined by 3gpp.

0 Unspecific service (Default Value)
1 PKI-Portal
2 Authentication Proxy
3 Presence
5 Liberty Alliance Project
6 UICC - Terminal Key Establishment
7 Terminal – Remote Device Key Establishment
9 GBA Push
10 IMS based PSS MBMS
11 OpenID GBA Interworking
12 Generic Push Layer

Type to SIM, that indicate what type to NAF key to be generated by BSF, Values are as Follow
GBA (Default)
Time for which GUSS values are valid
Security Feature that UE shall support.
"GPL_U": The UICC supports Generic Push Layer on the UICC
Integer Value of GAA Service Type Code
Shall contains the Public Identities IMPU that are associated with IMPI and shall be authorized to use GUSS.
GAA Authorization flag codes for Service types

PKI-Portal (1)
1    Authentication allowed
2    Non-repudiation allowed
0    Not authorized
1    Authorized according to policy stored in ANDSF server 
OpenID Interworking (13)
0    Not authorized
1    Authorized

It is an indication to BSF what types of NAF keys to be generated.
ME-based-key ---Ks_ NAF or Ks_ext_NAF shall be used
UICC-based-key  --- Ks_int_NAF
ME-UICC-based-keys ---- Ks_ext_NAF or Ks_int_NAF

Your Comments /Suggestions and Questions are always welcome,  shall clarify with best of knowledge. So feel free to put Questions.


  1. it maybe a stupid question: what is the purpose of bsf? the UE use it by what purpose?

    1. Hi,

      Generally it is used to authenticate 3gpp/Non-3gpp Access Network (Wifi etc.)

      Thanks for your query.
      Happy to help you again.

    2. Please provide more insight. 3GPP access is via eNb-MME-PCSCF and respective messages. Wheres as non-3GPP is ePDG-AAA-HSS and rest of nodes. Please share details how it got triggered under different technology and positioning of BGF. How does request reaches to BGF? What are it's connectivities?

  2. Hi,

    your previous answer is ok, but why the BSF is introduced, when there is already AAA server in the mobile networks? What are the differences in authentication functionality?



  3. The AAA server is used for a different purpose (WiFi authentication).
    The AAA server uses SWx interface towards HSS and BSF uses the Zh interface towards HSS.
    Both use MAR/MAA procedure with slightly different sets of parameters (AVPs).

    1. Hi Franz Edler,

      Thanks for your help.
      Appreciate your efforts.

  4. The BSF function is also used for the Ut interface for supplementary services in a non 3G network (if you so choose to implement this interface)

  5. This comment has been removed by the author.

  6. Anyone have a trace of this interface with WIFI

  7. the Ut interface is a joint name for the Ua, Ub, Zn, Zh, and AP-AS interfaces, over which VoLTE subscribers can manage supplementary services on their UEs.
    The VoLTE solution uses the Generic Bootstrapping Architecture (GBA) to guarantee the Ut interface security. The following two NEs are deployed between the UE and AS:

    Bootstrapping Server Function (BSF)

    Authenticates a UE by interworking with the UE and HLR and generated shared keys that are afterwards applied between the UE and the authentication proxy (AP).


    The AP authenticates service access requests from any UE. For the first service access request from a UE, the AP contacts the BSF for bootstrapping and then authenticates the service access based on the share keys generated.