Sh Interface – What Is It Good for?

There are main principles and there are small technical details. People mostly understand how a petrol engine works. But that doesn’t mean they are able to fix one or even make it. No, it is a long way to understand how things really work. And it is a psychologically proven fact that we can’t really understand things until we will try to change them. Well, don’t try it at home with your petrol engine.

This time we will take a closer look on one of often omitted interfaces. You don’t need it in order to understand the general idea of IMS but when we go into a detail it can be very important.

Sh Reference Point

The Sh interface is defined by 3GPP in TS 29.329 as a diameter interface between an AS and HSS.

Remember the third party registration? I admit I did’t tell you the whole truth. Shame on me. It can also look like this:

Sh interface in the third party registration

If you don’t believe anymore check the 3GPP TS 29.328.

So what operations are supported on Sh interface? There are two groups of them:

1. Data handling procedures
   – The download of data from the HSS to an AS
   – The update of data in the HSS.
2. Subscription/notification procedures
   – An AS can subscribe to receive notifications from the HSS of changes in data.
   – The HSS can notify an AS of changes in data for which the AS previously had subscribed.

In the first group we have:

User-Data-Request/Answer (AS -> HSS) 

This operation is used to download data for particular subscriber from HSS.

Profile-Update-Request/Answer (AS->HSS) 

In this operation AS stores/updates its data at HSS for a particular subscriber and/or application.

In the second group we have:

Subscribe-Notifications-Request/Answer(AS->HSS)

AS takes a subscription that when ever there is change in particular data field for a given subscriber. Note that in the SNA the HSS returns the user data, so we don’t need to send UDR if we want to do the SNR anyway.

Push-Notification-Request/Answer (HSS->AS)

HSS updates the AS for change in some particular subscriber profile if the AS has an active subscription.

During the Third-party Registration the S-CSCF creates so-called AS mapping for a given subscriber with the primary AS. Since that time the S-CSCF doesn’t use a general FQDN but the address received in Contact header of 200 OK. AS can also subscribe to S-CSCF for updates related to the subscriber.

Why we need the Sh when there is a SIP REGISTER/SUBSCRIBE/NOTIFY? The thing is the SIP messages in the 3rd party registration are intended for the Event: Reg. Meaning that the AS will not receive all information – subscriber or non subscriber data it needs for the application of service (e.g. There is no information in the SIP REGISTER or NOTIFY telling the RCS whether a particular user has some active news feeds or a permission to moderate video chats.) Sh operations are more sensitive and suitable for this purpose. A typical VoLTE flow would look like this:

Sh Interface in VoLTE flow

For registered users we can use instead of UDR/UDA the SNR/SNA (depends on the operator’s preferences). However not all the users are registered. Still time-to-time we need to apply some services for them (e.g. Call Forwarding to Voice Mail). In that case AS doesn’t have the subscriber profile in the memory and needs to retrieve the data – right, via Sh.

Sh for unregistered VoLTE subscribers

Because of geo-redundancy we always have at least 2 ASs. They are acting as primary servers for the users assigned during the third party registration (controlled by DNS). In case of a failure they act as a backup ASs too.

Sh for Failover

That means it can happen that some request doesn’t arrive on the primary AS (e.g. fail-over, request coming from Authentication Proxy or Sigtran network).  In that case the secondary AS will simply download the subscriber data from the HSS via the Sh interface.

VoLTE flow for Ut interface

For the VoLTE the ETSI TS 29.364 defines the XML format for service data descriptions for AS interoperability.

In some deployments we use an LDAP interface instead of the Sh for the data handling procedures. Depends on the preferences and on what vendors support. LDAP is usually being used along with SOAP protocol because not all the needed operations are supported by the LDAP. More information can be found in the post about HSS-FE.