Understanding the Home Subscriber Server (HSS) Sh interface
Pages: 1, 2, 3

Sh Interoperability Tests with Bridgewater Systems HSS

This section examines how we set up the test environment and how we drive the test with Bridgewater Systems. We start by presenting how we configure the environment, then we briefly discuss the Web application used in the test and a description of the messages exchanged between WebLogic SIP Server and the HSS. The system under test consists of two servers running the WLSS 2.2 instances, acting as a DIAMETER node, connected with the Bridgewater HSS. On one server two instances of WLSS will be running, one acting as an Admin Server, one as a DIAMETER node. The other DIAMETER node is running on the other server, as showed in Figure 3:

Architecture picture
Figure 3. The test environment

If you don't have a real HSS, you can download WLSS and use our HSS Simulator. Just follow these simple steps:

  • Download and install BEA WebLogic SIP Server 2.2 evaluation.
  • Configure a DIAMETER domain using the Configuration Wizard.
  • Download and deploy the application on a diameter Sh client node.

The Configuration Wizard includes a DIAMETER domain template that creates a domain with four WebLogic SIP Server instances:

  • An Administration Server
  • A Diameter Sh client node
  • A Diameter relay node
  • An HSS (HSS simulator)

Refer to the documentation on how to configure a diameter domain.

The application

The sample application presented in this article is a simple example built for testing in an easy way the message flow described in this article. The application lets you query and update the data stored in the HSS. It's possible to send out Sh-Pull, Sh-Update, and Sh-Subs-Notify requests using a simple Web interface. You can choose the user name, the type of request, the service name, in case of Sh-Pull, and the service data and service value in case of Sh-Update. This application shows that WLSS can successfully communicate with an HSS and conforms to 3GPP Technical Specification documents for the Sh interface.

WebApp Home Page
Figure 4. Show the home page of the Web application used to test Sh

There are three simple JSP pages: The Sh-Pull.jsp is used to test Sh-Pull request, the Sh-Update.jsp is used to test Sh-Update, and the Sh-Subs-Notif is used to test Sh-Subs-Notif. There is another special page, the profileViewer.jsp, which is used to query the HSS and get the full user profile. All you have to do is to insert the username in the field, and submit the form. In the web.xml you can find two parameters:

  • serverName - used to query for InitialFilterCriteria
  • serviceName - used to query the HSS with UDR and PUR and correspond with ServiceIndication

These parameters are read at startup and you can change them to meet your requirements. Once the connection with the HSS is established you can use those pages to query the HSS. In addition, the Web application prints out the ResultCode, the XML response generated by the HSS, and eventually the exception, as showed in Figure 5:

Figure 5
Figure 5. Show a simple PUR response (click the image for a full-size screen shot)

Step 1: Testing Connect Disconnect from the HSS

Just before the real connection, WLSS should be able to connect to an HSS server. In this case, WLSS should send a Capability-Exchange-Request (CER) to the configured HSS server: The HSS must return with a Capability-Exchange-Answer (CEA). The CEA is used to determine what diameter applications are supported by each peer.

Step 2: Testing Sh-Pull

After it has established the connection WLSS could send a User-Data-Request (UDR) request to the HSS Server: The HSS should correctly read the request and send a response User-Data-Answer (UDA). Going the other way, the application should be able to read the response: Each of them should match. The following diagram shows the behavior of the UDR:

Figure 6
Figure 6. Show UDR behavior (click the image for a full-size screen shot)

The preconditions for a positive test result are summarized below:

  1. The WLSS is connected to the Bridgewater HSS.
  2. The Base DIAMETER Stack is configured to communicate with the HSS.
  3. The user exists in the HSS.
  4. WLSS is in the HSS table list and the authorization of Repository Data for WLSS is set to readable.

Step 3: Testing Sh-Update

This command type can be used to update user data contained in the HSS. The same command can be also used to remove user information from the HSS. WLSS sends a Profile-Update-Request (PUR) toward the HSS that executes the update and replies with a Profile-Update-Answer (PUA) containing the result of the operation.

It is important to emphasize that a SIP Application Server can update/remove data about the services it is owning.

PUR Diagram
Figure 7. Show PUR behavior

The preconditions for a positive test result are summarized below:

  1. The WLSS is connected to the Bridgewater HSS.
  2. The Base DIAMETER Stack is configured to communicate with the HSS.
  3. The user exists in the HSS.
  4. WLSS in the HSS table list and the authorization of Repository Data for WLSS is set to writable.

Step 4: Testing Sh-Subs-Notif

The message is used by the WLSS to subscribe to a user that exists in the HSS. The WLSS sends a Subscribe-Notifications-Request (SNR) to receive notifications of user data changes specified in the SNR. The HSS acknowledges the SNR with a Subscribe-Notification-Answer (SNA). The same command is used to remove the subscription.

SNR Diagram
Figure 8. Show SNR behavior

The preconditions for a positive test result are summarized below:

  1. The WLSS is connected to the Bridgewater HSS.
  2. The Base DIAMETER Stack is configured to communicate with the HSS.
  3. The user exists in the HSS.
  4. WLSS is properly configured in the HSS table list and the Repository Data of WLSS is set to (Sh-Subs-Notif) available.

Step 5: Testing Sh-Notif

After a successful Sh Update request the HSS sends PNR messages to all previously subscribed entities. So, all WLSS entities being subscribed to receive change notifications will now receive PNR messages from the HSS. The PNR message contains details about the changed data. The WLSS answers the PNR with a Push-Notification-Answer (PNA).

PNR Diagram
Figure 9. PNR diagram



Introduced a few years ago, DIAMETER is proving to be the next-generation authentication, authorization, and accounting protocol for applications such as network access and IP mobility. It provides an extensible base protocol to deliver AAA services to new access technologies or applications. DIAMETER was originally designed to overcome issues in RADIUS such as security, reliability, lack of a peer-to-peer relationship between the client and the server, lack of real-time accounting, and standardization of usage in certain environments (some of these issues have been addressed by RADIUS extensions). The key drivers for DIAMETER deployments are focused around security, standardization to reduce costs and accelerate time to market, and the ability to roll out IMS.

This article explains the communication between the WebLogic SIP Server 2.2 and the Bridgewater HSS utilizing the Sh DIAMETER application. It describes the role of the HSS and how it stores data. Furthermore, the article explains how the WebLogic SIP Server retrieves and modifies this information. The sample Web application described in the article proves BEA's interoperability with Bridgewater's HSS, a leading industry provider of subscriber-centric policy management software for IP-based services.


  • RFC 3588 - DIAMETER base protocol
  • 3GPP TS 29.328 - Technical Specification Group Core Network and Terminals, P Multimedia (IM) Subsystem Sh interface; signalling flows and message contents
  • 3GPP TS.29.329 - Technical Specification Group Core Network and Terminals; Sh Interface-based on the DIAMETER protocol; protocol details


The author would like to thank Pascal Henry, Director of Market Development, Bridgewater Systems for his support, his contribution and for proof reading the article.


AAA: Authentication, Authorization, and Accounting
API: Application Programming Interface
AS: Application Server
CAMEL: Customized Application for Mobile network Enhanced Logic
CAP: Camel Application Part
CEA: Capability-Exchange-Answer
CER: Capability-Exchange-Response
CSCF: Call State Control Function
DOM: Document Object Model
EAP: Extensible Authentication Protocol
GSM: Global System for Mobile Communications
HSS: Home Subscriber Server
I-CSCF: Interrogating CSCF
ISC: IMS Service Control
IM-SSF: IP Multimedia Serving Switching Function
IMS: IP Multimedia Subsystem
IOT: Inter Operability Testing
NASREQ: Network Access Server Requirements
MSISDN: Mobile Subscriber International Services Digital Network
OSA: Open Service Architecture
OSA-SCS: OSA Service Capability Server
PNA: Push-Notification-Answer
PNR: Push-Notification-Response
PUA: Profile-Update-Answer
PUR: Profile-Update-Response
RADIUS: Remote Authentication Dial In User
S-CSCF: Serving CSCF
SIP: Session Initiation Protocol
SIP-AS: Sip Application Server
SNA: Subscribe-Notifications-Answer
SNR: Subscribe-Notifications-Response
UDA: User-Data-Answer
UDR: User-Data-Request
WLSS: WebLogic Sip Server
XML: Extensible Markup Language

Stefano Gioia is the WebLogic Sip Server Technology Specialist for BEA in EMEA. Focused on IMS opportunities with both operators and partners across Europe, the Middle East,and Africa