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 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
user-agent:3gpp-gba
x-3gpp-asserted-identity:"sip:+1234567890@ims.mnc123.mcc456.3gppnetwork.org"

<cp:rule id="cfu">
  <cp:conditions>
  </cp:conditions>
  <cp:actions>
    <forward-to>
      <target>
        tel:+987654321012
      </target>
    </forward-to>
  </cp:actions>
</cp:rule>

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

Authentication

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:

Boostraping

Boostraping

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.

Advertisements

12 thoughts on “Ut interface – what is it for?

  1. Pingback: Sh Interface – What Is It Good for? | Real Time Communication

  2. Pingback: At your service.. | Real Time Communication

  3. Pingback: Presence – More Than You Wanted to Know | Real Time Communication

  4. Pingback: WebRTC GW | Real Time Communication

  5. Pingback: IMS from 10.000 feet | Real Time Communication

  6. Pingback: Aggregation Proxy | Real Time Communication

  7. Pingback: XCAP Protocol | Real Time Communication

  8. Pingback: WebRTC and IMS | Real Time Communication

  9. Pingback: VoLTE in IMS | Real Time Communication

  10. Pingback: News: 2016 Summary | Real Time Communication

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

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s