Understanding the Home Subscriber Server (HSS) Sh interface

by Stefano Gioia


The Home Subscriber Server (HSS) is the master user database that supports IMS network entities that handle calls and sessions. This article explains the way in which a Home Subscriber Server can communicate with a WebLogic SIP Server (WLSS). It also discusses the different data that a WebLogic SIP Server can retrieve from the HSS and how this data can be updated. This article provides a general and technical introduction to the DIAMETER protocol and the Sh Interface, and shows the different types of requests that can be used by WLSS to retrieve user data for executing a service.

The second part of this article will focus on BEA's interoperability test (IOT) with Bridgewater Systems' HSS as an example of the communication between WLSS and the HSS. See the WebLogic Communications Platform developer center on Dev2Dev for additional articles that provide basic information about the SIP protocol and DIAMETER.


The Home Subscriber Server is the master user database that supports the IMS network entities that handle the calls/sessions. It contains user profiles, performs authentication and authorization of the user, and can provide information about the physical location of user. It's similar to the GSM Home Location Register. The entities that communicate with the HSS are the application server (AS) that hosts and execute services in the IMS environment, and the Call State Control Function servers (CSCF). The User Profile contains information about the current user—usually the S-CSCF downloads it uses when a user is registering on the network. The S-CSCF will receive the profile in a User-data Attribute Value Pair (AVP) format.

The 3GPP specs allow three types of ASes to function in the IMS network. Note that two out of the three are legacy (OSA and IM)

  • SIP AS: Specific to an IMS network
  • OSA-SCS: OSA Service Capabilities Server. This is an interface to OSA/Parlay
  • IM-SSF: IP Multimedia Server Switching Functions, exposing CAMEL Service to IMS

IMS Application Servers
Figure 1. Connection between HSS and other network entities

Each AS can optionally talk with an HSS using the DIAMETER Protocol over the Sh Interface (IM-SSF usually communicate using the Si interface). CSCF are used to process SIP signaling packets in the IMS network. There are two types of CSCF, connected to the HSS using DIAMETER Protocol over Cx Interface:

  • I-CSCF: Interrogating-CSCF
  • S-CSCF: Serving-CSCF is a SIP Server and performs session control. It's the central node of signaling plane. Usually every registered user has associated for the entire session the same S-CSCF

Let's now dive into the DIAMETER protocol before investigating the Sh interface and WebLogic SIP Server.

Background: The DIAMETER Protocol

The DIAMETER base protocol is a protocol that performs authentication, authorization, and accounting (AAA) in the IP Multimedia Subsystem and in the Next Generation Networks. The DIAMETER protocol is specified in RFC3588 and is the evolution of the well-known RADIUS protocol. The DIAMETER base protocol provides the capability negotiations between the network entities involved in the communication, the error notification, the delivery of the Attribute-Value-Pair, and the extensibility so you can add specific commands and new AVPs. DIAMETER can also operate in both local and roaming situations. Unlike SIP, DIAMETER uses binary encoding, but tools such as Ethereal allow easy decoding of the protocol messages, and it has been used in this interoperability test.

DIAMETER is designed in terms of a base protocol and an extensible set of applications, which means that the protocol is split in two parts: the base protocol, used for delivering the messages and error notifications, and negotiating the capabilities; and the DIAMETER application that defines new commands and data units. These new applications are, in our context, the Cx and Sh applications. The Cx application is primarily used to connect the CSCF to the HSS, while the Sh application is used by the application server, with the exception of the IM-SSF, which uses the Si application.

The application server, WebLogic SIP Server in this case, uses a command, that is, User-Data-Request (UDR), to request data. The HSS answers with a User-Data-Answer (UDA) that contains the requested data and a result code. This result code indicates if the request was successful or not. As an example, a successful operation will have the Result Code 2001 DIAMETER_SUCCESS.

Here is a list of terminology taken from RFC 3588 that may be involved in a DIAMETER communication (WLSS usually performs all the roles except the DIAMETER Server functions):

  • DIAMETER Agent: a DIAMETER node that provides either relay, proxy, redirect, or translation services
  • DIAMETER Client: a device at the edge of the network that performs access control
  • DIAMETER Node: a host process that implements the DIAMETER protocol, and acts either as a Client, Agent, or Server
  • DIAMETER Peer: a DIAMETER Node to which a given DIAMETER Node has a direct transport connection
  • DIAMETER Server: one that handles authentication, authorization, and accounting requests for a particular realm
  • Relay Agent: an entity that forwards requests and responses without modifying the message

Sh Application

Now it's time to introduce our main actor: the Sh application. This interface allows an application server to communicate with the HSS so that it can extract the necessary data to dispatch the logic of the service. Imagine a Call Screening service, where the user can configure the schedule of activation of the service. This data will be stored in the HSS and will be recovered by the WLSS for the activation of the service. Such data comes in two forms: transparent or not transparent, which means that the HSS understood syntactically but not semantically (transparent) while non-transparent means that the HSS can understand both syntactically and semantically. These kinds of data are unique to the user. This is what we call User Profile. Basically, a User Profile contains from one to many Service Profiles; each of them defines how the service must be executed.

The Sh interface protocol is defined as an IETF vendor-specific DIAMETER application, where the vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP is 10415, and the DIAMETER application identifier assigned to the Sh interface application is 16777217.

Sh data type

The list below summarizes the type of data that can be requested using an Sh application:

  • Repository data: contains transparent data related to the service
  • Public identifiers: contains a list of Public User Identity (PUI) associated to the user
  • IMS User State: contains the information about IMS User State of the public identifiers; the possible values are REGISTERED, NOT_REGISTERED, AUTHENTICATION_PENDING, REGISTERED_UNREG_SERVICES
  • S-CSCF Name: contains the address of the S-CSCF allocated to the user
  • Initial Filter Criteria: contains the triggering information for the service; an AS can only get the initial filter criteria related to the service provided
  • Location Information: contains the location information related to the user that could be located in Circuit-Switched (CS) or Packet-Switched (PS) domain
  • User State: contains the state of the user in the CS/PS domain
  • Charging information: contains the address of charging function
  • MSISDN: contains the MSISDN associated with the Public User Identity

Sh Data
Figure 2. Sh data UML diagram

The implementations of Sh interface in an application server can operate in two modes: Data Handling and Subscriptions/Notification.

  • Data Handling (Pull/Update)
    Data handling usually can be stored in Sh Pull (for getting data from the HSS) and Sh Update for storing data into the HSS. When you retrieve data from the HSS you're creating an Sh Pull request, and when you store data in to the HSS you're making an Sh Update request.
  • Subscription/Notifications
    The Subscriptions/Notifications mode allows the WLSS to get a notification when particular data for a specific user is updated in the HSS by other network entities.

Sh-specific commands

The commands specified by an Sh Interface are summarized in the following table:

  • UDR User-Data-Request, issued by the WLSS, is commonly used to request the user data that belongs to a particular user. After receiving the request. The HSS issues a UDA User-Data-Answer with the result code and the data itself.
  • PUR Profile-Update-Request, issued by the WLSS, is used to update the data stored in the HSS that will answer with a PUA Profile-Update-Answer. The data that can be stored on the HSS using the Sh application are limited only to data related to the service.
  • SNR Subscribe-Notifications-Request, issued by the WLSS, is used to mail or cancel a subscription to a user's data. The HSS will answer with a SNA Subscribe-Notification-Answer.
  • PNR Push-Notification-Request, issued by the HSS, is used to send the changed data to the WLSS currently subscribed.

Sh Permission List

Every time an AS makes a request for information related to a specific user, the HSS must verify if the AS has the necessary rights to issue the request. The HSS manages a Permission List, a list of rights granted to each AS. These rights are related to the aforementioned Sh-Pull, Sh-Update, and Sh-SubNotif and can be assigned one by one or in any combination. For example, an AS can be granted the Sh-Pull right but not the Sh-Update right. These rights are associated to all the users configured in the HSS.

Sh-specific failures

The Sh application specifies two kinds of failures: the permanent failure and the transient failure. The transient failures are used to inform a peer that the request could not be satisfied at the time that it was received. The request may be able to be satisfied in the future. These failures are used to inform one peer about a failed request (in a permanent or transient way). We will deal with these failures in greater detail in the section about the basic Interoperability Test (IOT) with a real HSS. You can find a list of permanent failures specified in the Sh application in 3GPP TS.29.329 specifications. Here you can find two examples from it (in brackets the Result-Code):

    The requested operation is not allowed for the user
    The requested user data is not allowed to be modified

Pages: 1, 2, 3

Next Page »