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.)
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.
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:+firstname.lastname@example.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:+email@example.com" <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.
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.
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.
Most of the terms are not familiar for me but still managed to understand the concept . Thanks
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.
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.
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.
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.
Each network is different, hard to judge – it’d help to see some sequence diagram, pcap, ..
Is this statement true?
“The UT is not mandatory. If UT does not support, then the Supplementary services” will go with CS domain.”
Are there any drawbacks to not implement UT interface and using SS with CS domain?+
Thanks in advance.
mandatory for what? For VoLTE as per GSMA standard? Yes. For a telco network implementing VoLTE service? No. Each operator has a different strategy and it is perfectly ok and quite common to have Supplementary Services, Prepaid Charging, etc. still in CS. In the long-term however it is expected, that the Supplementary Services will be done in IMS. As for the drawbacks – really depends on the context – as you probably still have to maintain CS, it maybe be cheaper and easier to support SS from CS. Once the majority of subscribers will be on IP, easier and more effective solution may be a Service Centralization in IMS. Hard to give any advice without a detail knowledge of the particular network.
LikeLiked by 1 person
thanks for your reply.
To give you more details about our network:
We are an Full MVNO and therefore we have got a CS and PS(HSS, PGW, PCRF) network already. We are at the beginning stage to implement VoLTE according to S8HR. Our plan is to have in the end of 2020 our own 5G SA-Core in parallel to 2G/3G/4G Core. Maybe you know, will be there any big differences between UT interface in 4G and 5G Network? If not, it would make more sense to implement UT interface right now.
If there are big differences between 4G and 5G SS, we should stick with SS over CS for our 4G network?
To my knowledge, there shouldn’t be any major changes when it comes to Ut in 5G. 23.228 in the version supporting 5G instead of ‘EPS’ often just says ‘EPS or 5GS’. The majority of changes are related to UE anyway. In fact – as described at https://realtimecommunication.wordpress.com/2017/10/31/ims-and-5g/ – for IMS the 5GS will be just another access network. Therefore, operators may use just one IMS for both EPC and 5GS.
Something I’d like to add:
If we stick with SS over CS, is the Authentication Proxy mandatory?
I don’t see any need for that. AP is used for IP access control.
when I am on IMS network and try to configure call forwarding services my network falls back to 3G. Does this mean it is not supported ut/XCAP?
It might be the reason – hard to judge without knowing the details
I am looking for open source implementation of 3GPP GBA. Do you know about any implementations like that?
Good question, but I don’t know about any open source 3gpp GBA. Let me know, if you find any.