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 Reference Point

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

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

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

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

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

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?

• Sh Interface – What Is It Good for?
• VoLTE in IMS
• At your service..
• XCAP Protocol
• Aggregation Proxy and Bootstraping

Advertisement