Understanding the Home Subscriber Server (HSS) Sh interface

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

Download

Conclusion

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.

References

  • 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

Acknowledgments

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.

Glossary

  1. AAA: Authentication, Authorization, and Accounting
  2. API: Application Programming Interface
  3. AS: Application Server
  4. CAMEL: Customized Application for Mobile network Enhanced Logic
  5. CAP: Camel Application Part
  6. CEA: Capability-Exchange-Answer
  7. CER: Capability-Exchange-Response
  8. CSCF: Call State Control Function
  9. DOM: Document Object Model
  10. EAP: Extensible Authentication Protocol
  11. GSM: Global System for Mobile Communications
  12. HSS: Home Subscriber Server
  13. I-CSCF: Interrogating CSCF
  14. ISC: IMS Service Control
  15. IM-SSF: IP Multimedia Serving Switching Function
  16. IMS: IP Multimedia Subsystem
  17. IOT: Inter Operability Testing
  18. NASREQ: Network Access Server Requirements
  19. MSISDN: Mobile Subscriber International Services Digital Network
  20. OSA: Open Service Architecture
  21. OSA-SCS: OSA Service Capability Server
  22. PNA: Push-Notification-Answer
  23. PNR: Push-Notification-Response
  24. PUA: Profile-Update-Answer
  25. PUR: Profile-Update-Response
  26. RADIUS: Remote Authentication Dial In User
  27. S-CSCF: Serving CSCF
  28. SIP: Session Initiation Protocol
  29. SIP-AS: Sip Application Server
  30. SNA: Subscribe-Notifications-Answer
  31. SNR: Subscribe-Notifications-Response
  32. UDA: User-Data-Answer
  33. UDR: User-Data-Request
  34. WLSS: WebLogic Sip Server
  35. 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