User Data Convergence – HSS-FE

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.)

User Data Convergence – HSS-FE

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.

Advertisement

Aggregation Proxy and Bootstraping

There were three telco engineers.

One was confused.

Second one was unsure.

And the third one also worked with IMS.

The self-confidence is a key for a trainer. And honestly that’s what I lack with IMS. There are so many things, specifications, flows which I’m not sure about. I can read several different specs about one network functionality, each claiming something slightly different but all of them very vague about some particular feature I’m interested in. That’s why I like the wireshark. The problem is that even the traces can differ deployment to deployment, vendor to vendor. But at least that is something I can touch.

When I started with the RCS I’ve seen various callflows which contained some ‘AP’ or ‘AG’ box. This network function is an http or ws API (REST/SOAP/XCAP/any other) gateway into the IMS network. I was a bit confused, because always it was called by a different name and the function was not always the same. It took me some time to sort it out (at least partially ;)).

We’ve already seen one of those boxes – the Authentication Proxy. This time we will discuss the Aggregation and Cross-Network Proxies. The Authentication proxy is standardized by GSMA as VoLTE network function. In contrast to that the Aggregation Proxy is an RCS network element defined by OMA in XML Document Management specs.

Otherwise they are very similar and in practice they can be implemented within the same physical system as both of them are used to allow users to manipulate data over http without the need to go through the SBC.

 

Aggregation Proxy

 

And indeed, when we take a closer look, we can see (as stated in the specification) that for a 3GPP IMS or 3GPP2 MMD realisation, the XDM-3 and XDM-5 reference points correspond to the Ut reference point. In other words Aggregation and Authentication proxy are supposed to work in the same way from the UE perspective (e.g. we’ll use GAA or Http Digest for authentication). We can reuse the BSF and NAF functionality we have implemented for Authentication proxy. So if we know the Authentication Proxy we already know most of the stuff.