XCAP architecture within the IMS

The following diagram illustrates Sentinel VoLTE’s XCAP architecture within the IMS:

ims xcap architecture
Tip XCAP’s use within IMS is described in 3GPP TS 33.222.

The Ut interface provides a user’s device with the ability to manipulate a configuration document. This document may contain user specific service settings such as privacy setting, communication barring and forwarding rules. TS 33.222 does not define how the MMTel-AS stores this document. However, 3GPP TS 29.364 defines a standardised XML schema for representing both the User and Operator settings for these services. TS 29.364 also defines the XML schema for transporting the user specific settings via the XCAP interface. This is called the "simservs" document. TS 29.364 also defines that an Application Server can store this service data on the HSS through the Sh interface as transparent data.

Sentinel VoLTE and XCAP

Sentinel VoLTE provides an XCAP server web application that implements the XCAP protocol towards the UE, and supports the XML schemas for user and operator data defined in TS 29.364, and stores and retrieves this information according to 29.364 in the HSS using Sh Transparent Data.

The diagram above shows several XCAP servers, as MMTEL-AS and Other-AS. Sentinel VoLTE provides the XCAP Server rather than the Authentication Proxy (AP) in the 3GPP architecture.

Sentinel VoLTE’s XCAP server application requires that the Ut/HTTP Requests have been Authenticated before reaching the XCAP application. Un-authenticated requests are rejected. Authentication may be achieved through use of the Sentinel Authentication Gateway product, or by using a separate Authentication Proxy.

The Sentinel Authentication Gateway is co-located with the XCAP server application rather than being a discrete AP. See Sentinel Authentication Gateway’s Architecture Overview for further information.

HTTP URIs and XCAP

The XCAP server is a web application that runs alongside other web applications. This means it does not run on the “root URI” of a host; rather, it runs on a URI relative to the root URI.

For example, if the XCAP host is running on xcap.server.net with port 8080, the base XCAP URL for the XCAP Server application will be

http://xcap.server.net:8080/rem/sentinel/xcap

The XCAP standards place the XCAP URI at the root of the host. As the base XCAP URL is not the root URI then either:

  1. URI re-writing may be required before HTTP requests arrive at the XCAP Server application, or

  2. UEs are configured to use the XCAP URL (a non “root URI”) rather than the “root URI”

If URI re-writing is required and Sentinel Authentication Gateway is used for authentication, then re-writing can be done via use of an HTTP proxy (such as Nginx) or web-server (such as Apache Web Server) between the UE and the combined Sentinel Authentication Gateway + XCAP Server Web application.

If a third party Authentication Proxy is used, then it may or may not support URI re-writing.

Active attributes inside the MMTel-Services document

There is a subtly worth noting with respect to the per-service "active" attribute in the User portion of each MMTel Service.

The active attribute is specified as an optional boolean attribute in the XML schema for the simservs and MMTel-Services documents.

In an XML document, this means they can have three possible values:

  • does not exist (that is, attribute is not declared)

  • exists with the value true

  • exists with the value false.

The specifications assign special meaning to these ‘active’ attributes when the attribute in the document does not exist:

  1. during session processing - logic should treat a non-existant attribute as though the value is true.

  2. XCAP requests from the user equipment are subject to special rules when the attribute does not exist:

    1. A request is not allowed to directly or indirectly create or otherwise modify a non-existant active attribute

    2. A request is allowed to configure other portions of that service’s data.

Regardless of the active flags state (existant, true, or false) a request can configure other portions of the service. For example, if Communication Diversion has no ‘active’ attribute, a request can configure communication diversion rules.

In summary, if an active flag is non-existant this means that the user equipment cannot disable the feature. If the operator wants the user equipment to be able to enable or disable the feature, then the ‘active’ attribute should exist (and therefore be either true or false).

Other notable restrictions of XCAP

If a user’s MMTel-Services document does not contain a named service (for example, <communication-diversion>) the UE cannot indirectly or directly create this element. Child elements of a named service can be modified/created/removed, provided that the named service is present.

The IMS Operator Determined Barring service has both session processing and XCAP related behaviour. The XCAP related Operator Determined barring behaviour enables the operator to disallow the a user’s capability to view and change their service settings.

Integration with Rhino Element Manager and Sentinel

The Sentinel XCAP server is a layer on top of the existing provisioning services and runs alongside the Sentinel REST machine API. XCAP is defined using REST principles and the implementation uses much of the same technology as the Sentinel REST API. It can be co-deployed with the Sentinel REST Provisioning API, and web human user interface, like this:

volte web container

Integrated components

The diagram above includes these components:

  • The HTTP clients can be:

    • a web browser

    • a provisioning application

    • an XCAP client (such as XCAP-enabled user equipment connecting through an aggregation proxy).

  • The HTTP servlet container configuration is used to specify the IP interfaces and port numbers that the REM Web application is running on. Therefore, if the port that the REM application is running on is to be reconfigured, the HTTP servlet container needs restarting.

  • The REM web application is packaged as a web archive (WAR). It can be deployed into various HTTP servlet containers. OpenCloud tests the application in Apache Tomcat and Jetty HTTP servlet containers.

  • The three HTTP-triggered components (web user interface, REST Provisioning API, and XCAP server) are triggered from the same port. The HTTP Request URI is used to distinguish which component processes a certain request.

Note Each of the components has their own security configuration.

Diameter Sh stacks and Rhino clusters

Each REM application includes one or more instances of the Diameter Sh stack. Each instance is scoped to the Rhino cluster it is associated with. The Rhino cluster is selected when the REM user selects a “Rhino instance” to log into.

Each instance of the Diameter Sh stack has Diameter peer configuration — including Realm tables for multiple Destination Realms. In other words, a single Diameter stack instance can be configured to connect to more than one distinct HSS.

Each instance of the Diameter Sh stack is shared by both the XCAP server and parts of the web user interface.

Each Rhino cluster has connectivity to various systems. (That connectivity is not shown in the diagram above.)

Previous page Next page