The more protocols you know, the more of the IMS you are. Right, the IMS is not only about SIP, Diameter or RTP. There are many various protocols involved. This time we’ll take a look at self-provisioning and configuration of services via http, more specifically XML Configuration Access Protocol (XCAP). We have seen it already in the posts about Ut Interface and Aggregation Gateway.
XCAP protocol is a kind of RESTful protocol. If you know a bit about the RESTfull approach, then you should easily become familiar with XCAP.
However the XCAP was created separately and has its own specifics. It was designed as a dedicated protocol for telecommunication environment as a set of conventions for mapping XML documents and document components into HTTP URIs, along with operations allowing to read/write/modify/delete these documents. That means it is not a general purpose XML search protocol. Still the XCAP is meant to support the configuration needs for a multiple applications such as supplementary services, capabilities, resource lists, presence rules and others.
Let’s take as an example the management of VoLTE supplementary services. XCAP allows an user to retrieve the information about the provisioned services and manage the content.
As we want to limit the amount of the exchanged data, XCAP allows to define the scope of the document we are working with. The scope can be the whole document, or an xml element or even only an attribute.
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.
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.
VoLTE and RCS support plenty of services – e.g. Call Forwarding, Call Barring or Presence. Some of these services can’t be pre-configured for the subscribers as each of them wants to provision his/her own forwarding/barred numbers or maybe doesn’t want to use the functionality at all. That means we need to have a way how to do a self-provisioning. In IMS we have a dedicated interface and network functionalities which allow to modify the setting of Supplementary Services and Presence Information directly from client (UE) via http/XCAP protocol. For VoLTE this is defined in the GSMA IR.92 and 3GPP TS 24.623, TS 24.423 and 3GPP TS 33.222. GSMA IR.92 directly says:
For supplementary service configuration, the UE and IMS core network must support XCAP at the Ut reference point as defined in 3GPP TS 24.623.
Wow – this is very important! There is not only the SIP/RTP between UE and IMS network but there can be also http (xcap)! Unlike SIP, HTTP is designed as a general-purpose data transport protocol. The purpose of SIP is mainly to create, modify, or terminate multimedia sessions. But sometimes we want to work with other types of data (e.g. configuration data, presence data, ..) which could easily overwhelm intermediate SIP proxies. HTTP is a good choice how to solve this issue.
What is the network architecture then?
As we can see the http traffic does’t go through the SBC but either directly or through an Authentication Proxy (AP) instead. The interface uses in cellular access the HOS APN (Home Operator Services) as defined in GSMA PRD IR.88 (in Wi-Fi either the HOS APN or a different APN as defined in of GSMA PRD IR.51). The usage of AP depends on the HOS APN (Home Operator Services) value. The Network Identifier (NI) part of the APN is undefined and must be set by the operator. The operators can choose to reuse an APN for already deployed services (e.g. Internet access, MMS, etc.) or choose a new, specific APN for the APN for Home Operator Services.
As the HOS APN is often using the standard Internet access, we’ll take a look at the flows with AP. The main purpose of AP is to authenticate user requests. It is also used to separate the authentication procedure and the Application Server (AS) specific logic (e.g. Supplementary Service provisioning) to different network entities.
(In case of presence and OMA XDMS architecture we talk about so-called Aggregation Proxy, which is described in its own post.)