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)
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:
Let's now dive into the DIAMETER protocol before investigating the Sh interface and WebLogic SIP Server.
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):
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.
The list below summarizes the type of data that can be requested using an Sh application:
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.
The commands specified by an Sh Interface are summarized in the following table:
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.
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):