I remember when I started with artificial neural networks. I read two books describing the mathematical models. Theoretically I had all information I needed, still I had no clue how to make a program which would do something. It took me quite some time to understand how to implement such a thing in C. Those were the days before the Internet and Google 🙂 But even nowadays there is a long, long way from an IMS functional design to a real network deployment.
No, I’m not going to go through the virtualization and all the networking stuff. Instead we will look at one of the options for HSS implementation. Usually we understand the Home Subscriber Server (HSS) as a database which is providing a support and capabilities for User Identity Handling and User Security, Access Authorization, Mobile Management, Service Profile and Authorization. We can also use Subscriber Location Function (SLF) in order to map a particular subscriber to the right HSS or for loadsharing.
The definition above associates a big monolithic system, which often it is. However for some operators this can be impractical as they have to store a lot of information about their subscribers in several different databases, they have to introduce new provisioning procedures etc. Instead they could have just one ldap data-storage and the HSS would only work with the data from this database. And that’s exactly what is known as User Data Convergence (UDC) concept. In fact this is not limited only to the HSS, but the approach applies also to other systems as HLR, Provisioning Server, or ENUM. (Technicaly there can be also more than one LDAP database – e.g. we can have a dedicated cAAA LDAP database, etc.)
In this case we don’t talk about HSS, but about HSS Front End (HSS-FE) and User Data Repository (UDR). The interface between the HSS-FE and UDR is called Ud and you can find its description in the 3GPP TS29.335 and 3GPP TS23.335.
The basic role of HSS-FE is to do the translation between Diameter Cx, Sh on one side and LDAP create, read, update and modify operations and SOAP Subscriptions and Notifications on the other side.
But that doesn’t mean that HSS-FE is only a dummy protocol converter. On contrary – the UDC concept separates the service logic and subscriber data. Just to resolve a particular Cx or Sh request HSS-FE can perform several different LDAP operations. The separation allows us independent scaling of the front end and the database. This design pattern is very standard these days, especially when it comes to web technologies or databases – we have a state-less edge proxy (e.g. nginx) and a state-full back-end (e.g Apache server).
Cx reference point
The Cx interface defines following operations:
- UAR/UAA (User-Authorization-Request/Answer)
- MAR/MAA (Multimedia-Authentication-Request/Answer)
- SAR/SAA (Server-Assignment-Request/Answer)
- LIR/LIA (Location-Info-Request/Answer)
- PPR/PPA (Push-Profile-Request/Answer)
- RTR/RTA (Registration-Termination-Request/Answer)
This interface is between I-CSCF, S-CSCF and HSS. We use it for registration, location query, profile download or update.
The UAR/UAA is the simplest request we can send during the registration from the IMS core to HSS-FE. The main goal is to retrieve the name of S-CSCF or its capabilities. For the HSS-FE it means only to send an LDAP request towards UDR and retrieve the response.
Anyway even this simple dialog can become more complex. For example it can happen that the configured S-CSCF is not available. Then the HSS-FE has to update the UDR (User Data Repository).
The whole registration can then look like this (for AKA)
There can be more LDAP requests needed for a single Cx operation. On the other side HSS-FE can also cache some information (on the service layer it is stateless though).
Note, that HSS-FE has to understand the content of the messages. E.g. based on the Authentication-Scheme the HSS-FE has to find out, how to retrieve the data (AKA via HLR, SIP Digest via UDR, GIBA via cAAA,..). Or based on the Server-Assignment-Type has to update UDR or send an error towards S-CSCF. So again – HSS-FE is not only a protocol converter.
Location is quite simple. The aim is to locate S-CSCF which handles a terminating user – IMPU or PSI. In order to provide localization service for an IMPU the I-CSCF sends LIR. It’s very similar to the scenario with UAR. However mind, that the terminating user is not always registered. Then the S-CSCF has to update the information in the subscriber database.
In case of a Public Service Identity (PSI) more steps (LDAP searches) can be needed in order to resolve a wild carded PSI.
User Profile Updates
If the operator modifies the content of the UDR, there has to be some mechanism how to trigger the HSS-FE. This can’t be done over LDAP (as the HSS-FE is an LDAP client). For this purpose we usually use the SOAP protocol. Between the HSS-FE and S-CSCF we then exchange PPR/PPA operations.
Network Initiated De-Registration
RTR/RTAA are nearly the same as PPR/PPA. Home network can trigger a de-registration (e.g. SIM card lost, contract expiry, network maintenance, multi-sim card scenarios .. ).
Sh reference point
The Sh interface defines following operations:
- UDR/UDA (User-Data-Request/Answer)
- SNR/SNA (Subscribe-Notification-Request/Answer)
- PUR/PUA (Profile-Update-Request/Answer)
- PNR/PNA (Push-Notification-Request/Answer)
The Sh reference point is between an Application Server and HSS. We’ve discussed this interface in detail already. As you probably sense, the UDR/UDA and PUR/PUA requests are very simple.
When one of the AS subscribes for changes the either the HSS-FE sends the PNR directly (in case there is some update for the user) or it is being triggered by UDR via SOAP (a different instance of HSS-FE can bi triggered).
ASs can also communicate directly with the UDR over LDAP/SOAP.
Zh reference point
The Zh interface defines following operations:
- MAR/MAA (Multimedia-Authentication-Request/Answer)
The Zh reference point is between the BSF and HSS. As we already know the MAR/MAA flows from the Cx interface, we can finally finish 🙂