Ut interface – what is it for?

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 Ut 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?

Ut interface, ut volte
Ut Reference Point

As we can see the http traffic does’t go through the SBC but through an Authentication Proxy (AP) instead. Its main purpose 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.)


The AP is configured as an HTTP reverse proxy. That means that the FQDN of the AS (e.g. MMTel) is configured to the AP in such a way that the IP traffic intended to the AS is routed to the AP. The AP performs the authentication of the UE. After the authentication procedure has been successfully completed, the AP assumes the typical role of a reverse proxy, i.e. the AP forwards HTTP requests originating from the UE to the correct AS, and returns the corresponding HTTP responses from the AS to the originating UE.

As mentioned the protocol for the Ut reference point is the XML Configuration Access Protocol (XCAP). XCAP defines two logical roles: XCAP client (UE) and XCAP servers (MMTel). XCAP protocol allows the client to read, write and modify application configuration data, stored in the server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. XCAP uses the HTTP methods PUT, GET, and DELETE to operate on XML documents stored in the server.

Authentication Proxy - Call Flow
Authentication Proxy – Call Flow

For the Supplementary Services the XML document is called simserv and it is defined in 3GPP TS 24.623.  The simservs XML document is composed of a common part, defined by the present document, and a number of XML fragments corresponding to each of the supplementary services.

PUT /simservs.ngn.etsi.org/users/sip:+1234567890@ims.mnc123.mcc456.3gppnetwork.org/simservs.xml/~~/simservs/cdiv/cp:ruleset/cp:ruleXYZ@id=cfu-12345ABC?xmlns(cp=urn:ietf:params:xml:ns:common-policy) HTTP/1.1
Accept: */*
Host: mmtel01.site01.operator.com
Connection: Close
Content-Type: application/xcap-el+xml

<cp:rule id="cfu">

The UE must configure only settings of one supplementary service per XCAP request. If the supplementary service to be configured contains an  element with multiple elements (RFC 4745) (e.g. as for CDIV or CB), then the UE must modify at most one element of the supplementary service per XCAP request.

In order to keep the state of supplementary services synchronized with the network elements and other terminals that the user might be using, the UE should subscribe to changes in the XCAP simserv documents by generating a SUBSCRIBE request. More information about XCAP can be found in the XCAP Protocol post.

MMTel/TAS does not persistently store the simservs XML document. The information from the simserv document is written to a backend database. E.g. over Sh Interface or Service Provisioning Markup Language (SPML) which is an XML-based framework for exchanging user, resource and service provisioning information.

Profile manipulation
Profile manipulation

For VoLTE an operator needs to ensure that supplementary service settings are the same in both VoLTE and CS networks. This can be achieved by synchronization between the CS and IMS/MMTEL. This is has been studied in 3GPP but finally no solution was standardized due to the complexity and different ways that such data is stored internally within the likes of the HSS/HLR and VoLTE MMTel AS.  A potential solution could be to utilize User Data Convergence (UDC) architecture.

Authentication Proxy + Sh Interface
Authentication Proxy + Sh Interface


For the authentication and security we usually use the TLS in the Generic Authentication Architecture (GAA) described in ETSI TS 33.220. Internally we divide the AP into two parts:

  • Network Application Function (NAF)

NAF is the reverse http proxy and handles the TLS security relation with the UE and relieves the application server (AS) of this task. Based on Generic Bootstrapping Architecture (GBA) the NAF can assure the AS that the request is coming from an authorized subscriber.

  • Bootstrapping server function (BSF)

BSF and the UE shall mutually authenticate using the AKA protocol, and agree on session keys (KS_NAF) that are afterwards applied between UE and NAF. The BSF shall be able to acquire the GBA user security settings (GUSS) from the HSS (via Zh).

Note that physically the NAF and BSF can be different servers. Actually the BSF is in the home network whereas the NAF can be located in a visited network.

The call flow with the GBA AKA looks as follows:


More details about bootstrapping procedure can found in the Aggregation Proxy and Bootstraping post or in ETSI TS 33.220 and 3GPP TS 29.109.

With the next request the UE doesn’t need to do the bootstraping again as the UE and NAF have already established the secure session.


Where next?

Print Friendly, PDF & Email


4G/5G, VoLTE, RCS, IMS, SIP, WebRTC, IoT/M2M Descrition, CallFlows, Illustrated Guides, Tests and other stuff for telco egineers

6 thoughts to “Ut interface – what is it for?”

    1. Dear Lalitha, thank you for your feedback. I agree that the post refers to many other elements and functionalities of IMS network. The target audience is the telco engineers, for others it can be a bit to complex to understand. Please let me know if there is anything in particular what deserves to explain in more detail.

  1. Hi great article! How does the UE know whether it can access the supplementary services through the uT interface? Is it told when it first attaches? is it preconfigured in the iSIM? cheers.

    1. Hi Magnus,
      In general the support of ut interface is mandatory. I believe you refer to APN for Home Operator Services discovery. The APN for Home Operator Services was formerly known as the “APN for XCAP/Ut”.

      The Network Identifier (NI) part of the APN is undefined and must be set by the Home Operator. The requirements for the value of the APN NI are as follows:
      • must be compliant to 3GPP TS 23.003
      • must resolve to a PGW in the HPMN; and
      • must not use the same value as the IMS well-known APN

      The APN for Home Operator Services utilizes a PGW always in the HPMN.

      The home operator can configure the UE with an XCAP Root URI. If the UE has not been configured with an XCAP Root URI, then the UE constructs an XCAP root URI as per 3GPP TS 23.003 (based on ISIM or USIM IMSI). As XCAP User Identity (XUI) the UE does use the default public user identity received in P-Associated-URI header in 200 OK for REGISTER.

      For more details please check IR.92 and IR.88.

      Kind Regards,

  2. Hi Karel,

    In our Case, we are not receiving any MAR from DRA ( Diameter Routing Agent ) for Zh. But our Supplementary services are working fine via Sh. How it is possible, there is no use of Zh, but all services are fine.


    1. Each network is different, hard to judge – it’d help to see some sequence diagram, pcap, ..

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.