Page 372 - From GMS to LTE

358 From GSM to LTE-Advanced Pro and 5G

bearer used for standard Internet connectivity is used. The reasons for this are that
some network operators support the IMS default bearer only on LTE but not necessarily
on the GSM or UMTS radio network and also because IMS connectivity is not neces-
sarily available while a subscriber is roaming outside the home country.
GSMA IR.92 allows different kinds of authentication mechanisms for the HTTP
exchange, for example, a challenge / response mechanism that uses the secret key on
the SIM card. Over HTTP, the challenge / response mechanism is implemented by the
mobile device sending the XCAP request without authentication information first. This
is then rejected by the network with a ‘HTTP 401 Unauthorized’ response containing
authentication information from the network side. The mobile device then forwards the
information contained in the challenge message to the SIM card, which generates the
required response values. The mobile then sends another HTTP XCAP request con-
taining the authentication response and the original XCAP request.
Before a request to the TAS supplementary service database can be sent over HTTP,
a DNS request is required to get the IP address of the server. The name to be queried is
standardized and contains the Mobile Country Code (MCC) and Mobile Network Code
(MNC) of the user’s home network operator and is structured as follows:
xcap.ims.mncXXX.mccXXX.pub.3gppnetwork.org
Once the IP address of the server has been obtained the mobile device then sends a
HTTP ‘GET’ request to get the current communication‐diversion settings from the
server. The request is standardized and contains, as shown in the example below, the
telephone number of the user for which the settings are to be read, the IMS identifier of
the home network operator and which kind of settings are to be read (in this case the
communication‐diversion settings):
GET /simservs.ngn.etsi.org/users/sip:+443393144238@ims. vodafone.
co.uk/simservs.xml/~~/simservs/communication-diversion HTTP/1.1
The TAS then returns an XML‐formatted response that contains the parameters of all
configured call forwarding (communication‐diversion) functions. The following excerpt
shows the part of the XML response that contains the current configuration of the call
forward no‐reply feature:
<communication‐diversion active=“true”>
<NoReplyTimer>25</NoReplyTimer>
[…]
<cp:ruleset>
[…]
<cp:rule id=“cfnry”>
<cp:conditions>
<rule‐deactivated/>
<no‐answer/>
</cp:conditions>
<cp:actions>
<forward-to>
<target>tel:+443397788990</target>
</forward-to>
</cp:actions>
</cp:rule>