Innovating Telecoms Training

VoLTE Initial Procedures

Reference Document

www.mpirical.com
VoLTE Initial Procedures

VoLTE Initial Procedures

Reference Document

MPI0126-000-010 © Mpirical Limited, 2021 i

 VoLTE Initial Procedures

Mpirical classes have been developed in accordance with the technical specifications
published by the 3GPP. As such the 3GPP have granted Mpirical Limited the right to use the
3GPP logo to identify specifications, compliant products and services.

First published by Mpirical Limited in 2017

© Mpirical Limited, 2021

All rights reserved. No part of this book or accompanying software may be reproduced or
transmitted in any form by any means, electronic, mechanical, photocopying, recording, or
otherwise without the prior written consent of the publisher. Although every precaution has
been taken in the preparation of this book the publisher assumes no responsibility for errors
and omissions. Nor is any liability assumed for damages resulting from the use of the
information contained within.

ii © Mpirical Limited, 2021 MPI0126-000-010

VoLTE Initial Procedures

Contents

IMS Identities......................................................................................................... 1 
1.1 Private User Identities ................................................................................... 1 
1.2 Public User Identities .................................................................................... 1 
1.3 USIM Derived Temporary Identities .............................................................. 3 
1.4 Public Service Identity ................................................................................... 4 
IMS Registration Analysis...................................................................................... 5 
2.1 LTE Network Specifics .................................................................................. 5 
2.2 IMS Network Specifics .................................................................................. 7 
IMS Registration Analysis – Initial Registration ..................................................... 7 
3.1 Initial Registration Request (UE to P-CSCF) ................................................ 7 
3.2 Forwarding the REGISTER (P-CSCF to I-CSCF) ......................................... 8 
3.3 S-CSCF Selection ......................................................................................... 8 
IMS Authentication and Key Agreement.............................................................. 10 
4.1 Authentication Vector Acquisition ................................................................ 10 
4.2 Authentication Challenge ............................................................................ 12 
Reregistration and Subscriber Profile Acquisition ............................................... 13 
5.1 Second Register .......................................................................................... 13 
5.2 Authentication and Subscriber Profile Acquisition ....................................... 14 
Registration Acceptance ..................................................................................... 15 
6.1 Third Party Registration .............................................................................. 16 
Registration Event Subscription .......................................................................... 16 
Service Configuration (Ut Interface) .................................................................... 17 

Glossary ............................................................................................ 21 

MPI0126-000-010 © Mpirical Limited, 2021 iii

VoLTE Initial Procedures

Figures

Figure 1 Storing the Private Identity .............................................................................. 1 

Figure 2 Key Features of the IMS Private Identity ........................................................ 1 
Figure 3 IMS Public Identities........................................................................................ 2 
Figure 4 Key Features of the IMS Public Identity .......................................................... 2 
Figure 5 Private and Public User Identity Relationship ................................................. 3 
Figure 6 Temporary Identities ........................................................................................ 3 

Figure 7 Implicit Registration ......................................................................................... 4 

Figure 8 Public Service Identities .................................................................................. 4 
Figure 9 Registration for VoLTE Services ..................................................................... 5 

Figure 10 LTE Flow of Events ....................................................................................... 5 

Figure 11 Establishing the PDN Connection to the IMS................................................ 6 
Figure 12 Home Operated Services APN ..................................................................... 6 

Figure 13 LTE Connectivity ........................................................................................... 6 

Figure 14 IMS Registration............................................................................................ 7 
Figure 15 Breakdown of Registration ............................................................................ 7 

Figure 16 Key Elements of the Registration Request ................................................... 7 

Figure 17 Querying DNS to Find an I-CSCF ................................................................. 8 
Figure 18 UAR and UAA Message Exchange (Initial Registration) .............................. 9 

Figure 19 Factors Effecting S-CSCF Selection ........................................................... 10 

Figure 20 Acquiring an Authentication Vector ............................................................. 11 
Figure 21 Generating the Authentication Vector ......................................................... 11 
Figure 22 Authentication Pending Flag ....................................................................... 12 
Figure 23 Authentication Challenge ............................................................................ 12 
Figure 24 IMS Registration (2nd Attempt) .................................................................... 13 
Figure 25 UAR and UAA Message Exchange (Reregistration) ................................... 14 
Figure 26 Information Stored in the S-CSCF on Successful Authentication ............... 14 
Figure 27 SAR and SAA Message Exchange ............................................................. 14 

Figure 28 Service Profile ............................................................................................. 15 

Figure 29 Key Header Fields in the 200OK ................................................................ 15 
Figure 30 Third Party Registration .............................................................................. 16 

MPI0126-000-010 © Mpirical Limited, 2021 v

 VoLTE Initial Procedures

Figure 31 Register Event Subscription ........................................................................ 17 

Figure 32 Service Configuration via Ut Interface ........................................................ 18 
Figure 33 Manipulating the XML Document using HTTP Commands ........................ 18 
Figure 34 XCAP Application Usages ........................................................................... 19 

vi © Mpirical Limited, 2021 MPI0126-000-010

VoLTE Initial Procedures

IMS Identities
1.1 Private User Identities
VoLTE subscribers are allocated a private identity by their home network
service provider; this is used in the Registration, Authorization, and
Accounting processes employed by the IMS. The private identity takes the
format of a NAI (Network Access Identifier), which identifies both the
subscriber and their home network. This NAI will often include a
representation of the IMSI (International Mobile Subscriber Identity).
The private identity of the user is stored in the HSS (Home Subscriber Server)
and the ISIM (IMS Subscriber Identity Module), or if the mobile does not
contain an ISIM, then the private identity may be derived from the IMSI
parameters held on the USIM (Universal Subscriber Identity Module), if
available. If the device contains neither an ISIM or a USIM ie a non-3GPP
device, IMC (IMS Credentials) will be used. This is effectively a generic term
for whichever storage mechanism the device uses for any IMS security data
and functions that are required for IMS access.
Figure 1 shows an example of a VoLTE Private Identity, which includes the
IMSI as the subscriber identifier.

Derived from
ISIM IMC
USIM Credentials

Username = 234997273100339 @imsnet.com

Figure 1 Storing the Private Identity

Figure 2 outlines a selection of key features associated with the IMS Private
Identity.

Not used for

Shortened to Required for IMS
routing SIP
IMPI Registration
signalling
Stored by HSS
Identifies the and also by
subscription S-CSCF
(post registration)

Figure 2 Key Features of the IMS Private Identity

1.2 Public User Identities

VoLTE subscribers, as well as a private identity, will also have one or more
associated public identities that will act as the subscriber’s SIP Address of
Record. The Public Identity is what other IMS users will utilize in order to
contact the subscriber.
Consequently, these addresses will be used in the registration process to bind
a user’s Public address to a specific SIP User Agent. These addresses will
typically take the form of a SIP URI as described above, but may also take the
format of a Tel URI (tel:+441541456589, with the + indicating this format of
number is based on the E.164 numbering plan). It should be noted however
that messages in the IMS are routed on the basis of a SIP URI and as such, if

MPI0126-000-010 © Mpirical Limited, 2021 1

 VoLTE Initial Procedures

a Tel URI is used, it must be converted to a SIP URI as appropriate. This can
be achieved using the IETF ENUM (e164 to SIP URI Mapping) system.
VoLTE subscribers will have at least two Public IDs:
 A SIP URI which contains the MSISDN of the subscriber.
 A Tel URI which also contains the MSISDN of the subscriber.
 Additional Public IDs are permissible and can be in alternative formats
such as alpha characters eg sip:johnsmith@mpiricalvolte.com.

Public
sip:+447872718782 @mpiricalvolte.com;user=phone
Identity

VoLTE Service

Public
tel:+447872718782
Identity

Figure 3 IMS Public Identities

A selection of key points associated with IMS Public Identities are outlined in
Figure 4.

IMPUs can be
Shortened to IMPUs are not
part of Implicit
IMPU authenticated
Registration sets

IMPU can be
IMPU could be a
used for SIP
tel: URI
routing

Figure 4 Key Features of the IMS Public Identity

At least one Public User Identity must be stored on a UE ISIM. If a Public

User Identity is not available, a Temporary Public User Identity must be
derived.

Relationship between Private and Public User Identities

While a user’s subscription will associate them with their private identity, this
in turn may be associated with a number of public identities. Note that in
Figure 5, two separate service profiles are associated with the same IMS
subscription (the same Private Identity).
The relationship between the private and public identities, along with their
assignment, is done through the registration process and interaction between
the S-CSCF (Serving Call Session Control Function) and the HSS (Home
Subscriber Server). These public identities are also associated with a service
profile, which is downloaded to the S-CSCF when a user registers.

2 © Mpirical Limited, 2021 MPI0126-000-010

VoLTE Initial Procedures

Figure 5 Private and Public User Identity Relationship

In order to register a user, the S-CSCF must be supplied with a suitable

Private and Public User Identity by the user as part of the SIP REGISTER
process.

1.3 USIM Derived Temporary Identities

For service providers wishing to roll out VoLTE, providing subscribers with a
new SIM card, specifically an ISIM, could be a significant cost. However, the
3GPP have standardized a mechanism by which the credentials on a USIM
can also be used to successfully register with the IMS.
The technique is based on the derivation of a Temporary Public and Private
ID, each of which are created with the use of the IMSI stored on the USIM.
Figure 6 outlines the standardized step by step process.

Figure 6 Temporary Identities

Implicit Registration
USIM based registration necessitates the use of Implicit Registration, since
the Temporary Public ID derived from the USIM is just that; temporary. As
such, the mobile needs to be supplied with the correct Public IDs that it must
use once registration is complete.
Implicit registration uses the concept of an Implicitly Registered ID Set. These
sets are essentially groups of public identities which will all be registered at

MPI0126-000-010 © Mpirical Limited, 2021 3

 VoLTE Initial Procedures

the same time if and when a SIP REGISTER containing any of the public
identities in the set is sent to the IMS. In other words, you only need to
register one public address and in doing so, every other public address which
shares the same Implicitly Registered ID Set will also be registered. This
process is outlined in Figure 7:

Figure 7 Implicit Registration

Therefore, if the service provider wishes to use temporary IDs, the HSS must
contain an Implicitly Registered ID Set which includes the temporary Public
ID, plus the real public IDs that the subscriber will eventually need to use
(once registered, the temporary ID will typically not be used for any other
procedures).
The SIP P-Associated-URI header field within the 200OK to the REGISTER
will contain a list of successfully registered Public IDs.

1.4 Public Service Identity

As the name suggests, PSI (Public Service Identity) identify services which
are hosted by Application Servers, as opposed to Public User Identities which
identify IMS subscribers. Standardized services such as conferencing,
presence and instant messaging can all employ PSIs.
In particular, a PSI can be used to identify IMS Groups, which are essentially
groups of IMS subscribers. To illustrate, a subscriber may have a
preconfigured group on a presence AS and when that subscriber sends a
SUBSCRIBE to the PSI of that group, presence information for all members of
the group will be monitored.

Figure 8 Public Service Identities

PSIs are typically in the form of a SIP URI or TEL URI, as shown in Figure 8.

4 © Mpirical Limited, 2021 MPI0126-000-010

VoLTE Initial Procedures

IMS Registration Analysis

2.1 LTE Network Specifics
In order to conduct calls using VoLTE, the LTE mobile must register with the
IMS for VoLTE services. Fundamentally, the mobile must first of all be
informed that VoLTE services are available. This is achieved during the Initial
Attach or TAU (Tracking Area Update), whereby an information element
termed EPS Network Feature Support will indicate that "IMS Voice over PS
Session" is available (this information is sent in NAS (Non Access Stratum)
signalling from the MME to the mobile).

MME

Attach Procedure

NAS Attach Accept

EPS Network Feature Support :
IMS Voice over PS Session Available

Figure 9 Registration for VoLTE Services

LTE Flow of Events

Although the mobile finds out about network support for VoLTE during the
Attach or Tracking Area Update, during that procedure it is not necessarily
establishing a PDN connection to the IMS. Although it is network dependent, it
is not unusual to see the mobile first of all establishing Internet connectivity
during the Attach.
Following the Attach, the mobile will then conduct a separate PDN
Connectivity procedure, with the IMS identified as the APN (Access Point
Name).

PDN
Internet IMS APN
Initial Attach Connectivity
Connectivity Connectivity
Request

Figure 10 LTE Flow of Events

During this separate PDN connection procedure, the mobile will be supplied
with the P-CSCF IP address, which sits as the payload of PCO (Protocol
Configuration Options) within the “Activate Default EPS Bearer Request" NAS
message (specifically the container identified as “P-CSCF IPv4/IPv6
Address”). Consequently, when the device is eventually ready to conduct the
IMS registration, it knows to which IP address it must send the SIP
REGISTER.

MPI0126-000-010 © Mpirical Limited, 2021 5

 VoLTE Initial Procedures

Figure 11 Establishing the PDN Connection to the IMS

Home Operated Services

It is possible that after the PDN connection to the IMS is established, a further
PDN connection is established to the HOS (Home Operated Services) APN.
Although this could be in support of connectivity to RCS (Rich Communication
Services) services, it may also/alternatively be in support of the Ut interface,
which is there to provide over the air configuration of a subscriber’s services.
See Figure 32 for further details.

Figure 12 Home Operated Services APN

Connectivity to the HOS APN can allow the mobile to configure its services
utilizing XCAP (XML Configuration Access Protocol). For example, this would
allow the subscriber to configure their VoLTE supplementary services or
contacts on their social presence list. See Figure 32 and Figure 34 for further
information.
Figure 13 summarizes the potential LTE connectivity which could be in place
following the LTE initial procedures.

Figure 13 LTE Connectivity

6 © Mpirical Limited, 2021 MPI0126-000-010

VoLTE Initial Procedures

2.2 IMS Network Specifics

P I S
CSCF CSCF CSCF AuC
HSS
ISIM
REGISTER
REGISTER
UAR

UAA

REGISTER
MAR

MAA
401 Unauthorized
REGISTER
UAR

UAA

REGISTER
SAR

SAA
200OK

Figure 14 IMS Registration

The IMS Registration procedure is outlined in Figure 14.

In order to analyze the process in a logical manner, the registration has been
broken down into several phases, each of which will be analyzed in turn.

Reregistration and
Registration Registration
Initial Registration Subscriber Profile
Security Acceptance
Acquisition

Figure 15 Breakdown of Registration

IMS Registration Analysis – Initial Registration

3.1 Initial Registration Request (UE to P-CSCF)
Once the IP address of the P-CSCF is known by the mobile, the Initial
Registration Request message can be sent in order to trigger off the overall
registration process. Figure 16 outlines some of the key information that the
mobile is required to share with the network.

Private ID Public ID Contact Address

(IMSI) (MSISDN) (IP Address)

Terminal Security E-UTRAN

Capabilities Information Location
(mmtel) (AKA) (LTE Cell)

Figure 16 Key Elements of the Registration Request

MPI0126-000-010 © Mpirical Limited, 2021 7

 VoLTE Initial Procedures

 Private ID – used as a reference to the subscriber by the network,

particularly when acquiring authentication information from the HSS.
 Public ID – the ID to which the contact address will be associated at the
S-CSCF (with implicit registration, this one identity could be
representative of several additional Public IDs).
 Contact Address – the IP Address of the mobile.
 Terminal Capabilities – these will be listed as parameters of the
Contact: field in the SIP signalling.
 IMS Multimedia Telephony Service1 (urn:urn-7:3gpp-
service.ims.icsi.mmtel).
 SMS over IP2 (+g.3gpp.smsip) – if SMS over IP is supported.
 Video – if ViLTE is supported.
 Security Information – in order to facilitate authentication of the VoLTE
subscriber.
 E-UTRAN location – defining the LTE cell that the subscriber is
currently in.

3.2 Forwarding the REGISTER (P-CSCF to I-CSCF)

Due to the fact that a roaming scenario may be in operation, the registration
request is always forwarded from the P-CSCF to an I-CSCF, even if both
devices are in the home network. If it was a roaming scenario, the P-CSCF
would be in the visited network and the I-CSCF would sit on the border of the
home network. For message routing purposes, the Request URI of the
register will indicate the home IMS domain.
In order to ascertain which I-CSCF should be utilized, the P-CSCF typically
sends a DNS query, as shown in Figure 17.

Figure 17 Querying DNS to Find an I-CSCF

An alternative approach, particularly when the P, I and S CSCFs are part of a

combined node, is to have a default I-CSCF that the P-CSCF will always use.
Before forwarding the REGISTER, the P-CSCF will add its address to the
Path: header field, which causes all future signalling traffic related to
multimedia sessions to be forced through this Proxy. The S-CSCF will store
this P-CSCF address upon successful registration.

3.3 S-CSCF Selection

The HSS will supply information to the I-CSCF related to the capabilities that
the S-CSCF must support (eg features, role, geographical location), as well as
any per user preferences that the service provider may wish to use.

1
3GPP TS 24.173 - IMS multimedia telephony communication service and supplementary services
2
3GPP TS 24.341 - Support of SMS over IP networks

8 © Mpirical Limited, 2021 MPI0126-000-010

VoLTE Initial Procedures

This information is acquired using the Diameter UAR (User Authorization

Request) and UAA (User Authorization Answer) message exchange.
As the title suggests, the UAR is an initial check to verify whether the
subscriber’s request is authorized. In particular, the HSS will verify whether
the IMPI and IMPU of the user are recognized and legitimate, as well as
actually associated with one another. In addition, the HSS will verify whether
or not the subscriber is barred from establishing multimedia sessions.
The key elements of the UAR and UAA are outlined in Figure 18.

Figure 18 UAR and UAA Message Exchange (Initial Registration)

 Public User Identity - this will be used by the HSS to identify the service
profile that the user wishes to use.
 Private User Identity - this will be in the format of an NAI (Network
Access Identifier). It associates a user with their subscription records
as well as authentication keys that will be used in the subsequent
authentication process.
 Visited Network Identity - this variable will be checked by the HSS to
ensure the subscriber is entitled to roam into the visited network.
 Type of Authorization - this will indicate the type of signalling that
prompted the interaction with the HSS. This may include Registration,
De-Registration or Registration and Capabilities. The latter will be used
if the I-CSCF requires the capabilities of the S-CSCF. This will normally
be invoked if the I-CSCF has lost dialog with the S-CSCF and is
requesting an alternative from the HSS.
If the UAR is accepted and the Registration is an Initial Registration, as in this
case, the HSS will set the result code to Diameter_First_Registration and
return a list of S-CSCF capabilities to the I-CSCF. Note that the Server
Capabilities AVP in the UAA of Figure 18 is populated with information based
on the service profile for the subscriber (the Private ID is supplied in the UAR
so that the HSS can access the correct service profile).
Once the I-CSCF knows which server capabilities the chosen S-CSCF must
support, it will allocate a S-CSCF. To achieve this, the I-CSCF must already
know which S-CSCFs in the network have which capabilities. This information
is preconfigured by the service provider during network rollout. Introduction of
additional S-CSCFs will mean that the I-CSCFs must be updated with their
capability information.
Certain additional criteria may also be supplied to the I-CSCF which can
influence the S-CSCF selection decision. This is show in Figure 19.

MPI0126-000-010 © Mpirical Limited, 2021 9

 VoLTE Initial Procedures

User Location Topological S-CSCF Load

(based on Location of Balancing
P-CSCF in use) S-CSCF (based on DNS)

Figure 19 Factors Effecting S-CSCF Selection

Forwarding the REGISTER (I-CSCF to S-CSCF)

Once the S-CSCF has been selected, the I-CSCF will forward the register to
the S-CSCF. The I-CSCF will add its own address as a via: field entry but
apart from this, there is no other information added.

IMS Authentication and Key Agreement

Assuming there are no simultaneous registration issues, the next stage is to
determine what kind of authentication is to take place. Any users accessing
the IMS via a 3GPP based access network will use IMS AKA (Authentication
and Key Agreement) by default. Therefore, VoLTE will use IMS AKA for its
authentication mechanism, which is based on the ISIM or USIM being present
on the device.
IMS AKA is modelled on UMTS AKA. This architecture requires the mobile
and the HSS to have access to a shared copy of a secret key, termed K.
Using K and the same algorithms found in the UMTS AKA process,
authentication, encryption and integrity variables can be derived at both the
mobile and the HSS.
In terms of Authentication, RES (Response) and MAC-A (Message
Authentication Code - Authentication) are exchanged between the mobile and
the S-CSCF in order to support mutual authentication. That is, the S-CSCF
checks that the subscriber terminal is genuine (using RES) and the subscriber
terminal checks that the IMS network is genuine (Using AUTN).
With regard to encryption and integrity checking, Kc and Ki are held at the P-
CSCF and can also be generated at the subscriber terminal. These keys will
be used in a bidirectional IPSec Security Association between the terminal
and the P-CSCF in order to protect all IMS signalling as it crosses the
potentially insecure IP-CAN.
It should be noted that in the case of VoLTE, the user will have to carry out
EPS AKA before IMS AKA, which will result in the mobile having to manage
several security associations with the network. As such, the service provider
may opt to use integrity checking of SIP signalling only, choosing not to
encrypt SIP signalling between the mobile and P-CSCF (in VoLTE, support for
integrity checking is mandatory whereas support for encryption is optional).

4.1 Authentication Vector Acquisition

In order to conduct IMS AKA, the S-CSCF must formulate an authentication
challenge in the guise of a SIP 401 Unauthorized message. However, before
formulating this message, the S-CSCF must acquire an authentication vector
from the HSS. This is achieved using the Diameter MAR (Multimedia
Authentication Request) and MAA (Multimedia Authentication Answer)
message exchange, as outlined in Figure 20

10 © Mpirical Limited, 2021 MPI0126-000-010

VoLTE Initial Procedures

IK

Figure 20 Acquiring an Authentication Vector

IMS-AKA Authentication Vector Generation

When the HSS receives the MAR, it will extract the Private ID in order to
acquire the correct K (Subscriber Authentication Key), which is used to
generate the Authentication Vector.
The derivation of the Authentication Vector (often termed a Quintet), is
illustrated in Figure 21. The 128bit value K (Subscriber Authentication Key) is
only stored at the HSS and the ISIM (IMS Subscriber Identity Module) and
must be verified by the authentication process. The AMF (Authentication
Management Field) is comprised of 16bits and may be used to set the
acceptable synchronization window in both the UE (User Equipment) and
network. The SQN (Sequence Number) is comprised of 48bits and should
increment after each successive authentication. Finally, the RAND is a 128bit
random number which is generated by the HSS.
These values are fed into the various functions to produce the following
security parameters:
RAND K SQN

AMF
f1 f2 f3 f4 f5 xor
SQN

MAC-A XRES CK IK AK SQN AK

AUTN = SQN [ AK] AMF MAC-A

AV = (RAND, XRES, CK, IK, AUTN)

Figure 21 Generating the Authentication Vector

 MAC-A (Message Authentication Code - Authentication) is used to

authenticate the network to the subscriber. It is comprised of 64bits and
authenticates the data integrity and the data origin of RAND, SQN and
AMF.
 XRES (Expected Response) is used to authenticate the subscriber to
the network. It is comprised of between 32bits and 128bits (multiples of
8bits).
 CK (Cipher Key) is comprised of 128bits and is used during the
encryption and decryption of data.

MPI0126-000-010 © Mpirical Limited, 2021 11

 VoLTE Initial Procedures

 IK (Integrity Key) is comprised of 128bits and is used to verify the

integrity of signalling messages passed between the subscriber and the
network.
 AK (Anonymity Key) is comprised of 48bits and may be used to
conceal the value of SQN.
A key point to note is that once the MAA has been sent, the HSS will
associate the Private ID of the subscriber with an “Authentication Pending”
flag, and also remember the identity of the S-CSCF.

Figure 22 Authentication Pending Flag

4.2 Authentication Challenge

At this stage, the S-CSCF will formulate the 401 Unauthorized authentication
challenge, which will contain 4 elements of the authentication vector supplied
in the MAA (retaining XRES):
 RAND.
 AUTN.
 CK.
 IK.
The 401 Unauthorized messages will follow the reverse path through the
network, until it arrives at the mobile. On the way, IK and CK will be removed
by the P-CSCF, for two reasons. Firstly, at present the Gm reference point
(UE-P-CSCF) is insecure. Secondly, the P-CSCF will need these security
parameters in order to set up its end of the security association that it will
make with the mobile.

Figure 23 Authentication Challenge

12 © Mpirical Limited, 2021 MPI0126-000-010

VoLTE Initial Procedures

Reregistration and Subscriber Profile Acquisition

P I S
CSCF CSCF CSCF AuC
HSS
ISIM
REGISTER
REGISTER
UAR

UAA

REGISTER
MAR

MAA
401 Unauthorized
REGISTER
UAR

UAA

REGISTER
SAR

SAA
200OK

Figure 24 IMS Registration (2nd Attempt)

5.1 Second Register

On receipt of the 401 Unauthorized response, the mobile can extract the
RAND and AUTN values. Bearing in mind that the ISIM held on the device
should have a copy of the secret key K and has just received the RAND, it
should be able to recreate the authentication vector.
Once the authentication vector is created, the first step is to verify that the
Authentication Token, AUTN, is correct. Assuming that it is, the mobile will
generate a new registration request, with the key difference that this time, the
Authorization: header field will be populated with an authentication response.
In addition, the mobile will also create the appropriate CK and IK values which
can be used to securely communicate with the P-CSCF via a security
association.

Second Register (P-CSCF to I-CSCF)

In essence, the reregistration is considered to be a standalone registration
attempt and as such, the P-CSCF will still need to forward the REGISTER to
an I-CSCF. Once again, the services of DNS can be used to achieve this and
the process is applicable to home or roaming operation.

Second Register (I-CSCF to S-CSCF)

At this stage the I-CSCF will behave in the same manner as the previous
register, with one key difference; the HSS currently has an authentication
pending flag set for this particular subscriber. As such, the HSS will return the
Server Name AVP in the UAA response which details the S-CSCF handling
the authentication process for this subscriber. This is shown in Figure 25.

MPI0126-000-010 © Mpirical Limited, 2021 13

 VoLTE Initial Procedures

Figure 25 UAR and UAA Message Exchange (Reregistration)

Once the I-CSCF acquires the identity of the S-CSCF, it can route the SIP
REGISTER towards it.

5.2 Authentication and Subscriber Profile Acquisition

When the SIP REGISTER arrives at the S-CSCF, the RES value is extracted
from the Authorization: field and compared to the stored XRES value. If the
expected response is the same as the authentication challenge response, the
Public Identity of the subscriber will be registered in the S-CSCF, along with a
series of additional information, as outlined in Figure 26.

Figure 26 Information Stored in the S-CSCF on Successful Authentication

The service profile must be acquired from the HSS before the S-CSCF
responds to the mobile. This is achieved through the SAR (Server Assignment
Request) and SAA (Server Assignment Answer) message exchange.

Figure 27 SAR and SAA Message Exchange

Service Profile
Registration in the IMS is not just about binding a user's public ID to a contact
address. One of the fundamental aims of registration is to ensure that a user's
service profile(s) is downloaded to the S-CSCF in order to ensure that future
requests for services will be correctly handled. As such, each public user ID
that a user has must be associated with a service profile.
The service profile will contain the Core Network Service Authorization
parameters, which in turn contain media profiles and capabilities of the user.
Initial Filter Criteria (termed ifc) are also included. This contains information

14 © Mpirical Limited, 2021 MPI0126-000-010

VoLTE Initial Procedures

regarding the AS (Application Server) associated with the service profile and a
list of trigger points that, if the criteria are met, will initiate a dialog with the
referenced AS.
Figure 28 shows the typical architecture of a service profile, showing the
relationship between the public identity and the authorization parameters in
terms of media profiles and filter criteria.

Service Profile

Public Identity Core Network Authorization Initial Filter Criteria

SIP URL Media Profile a Trigger Application

Tel URL Media Profile b Points Server

Figure 28 Service Profile

Initial Filter Criteria are based on the information presented in the header of
the SIP messages and can include:
 URI - this will indicate the type of user or service the user is wishing to
establish a session with.
 Methods - this indicates the service that the user wishes to solicit. This
may include options such as instant messaging, call forwarding or
conference bridging.
 Headers - these provide more specific details of the service required.
 Session Description - this describes the media bearers etc that are
requested. This information within the profile may be used to influence
policy and charging control at the P-CSCF (Proxy Call Session Control
Function) and the negotiation of QoS (Quality of Service) at the bearer
level.
Downloading of Filter Criteria as part of the Service Profile download from the
HSS is a crucial part of the registration process. In subsequent requests for
services from the subscriber, it is the Filter Criteria which inform the S-CSCF
which AS to use to invoke the desired service.
It should be noted however that a typical registration procedure may not
include the subscriber profile in the payload of the SAA message. This is
usually due to the fact that all subscribers receive the same “default”
subscriber profile which is preconfigured in the S-CSCF.

Registration Acceptance
Once the service profiles for the subscriber have been downloaded to the S-
CSCF, the S-CSCF will be configured to handle future service requests. At
this point, the S-CSCF will return a 200OK, denoting a successful registration.
There are two key elements of the 200OK that the S-CSCF must include
within the 200OK:

Service -Route P-Associated URI

Figure 29 Key Header Fields in the 200OK

MPI0126-000-010 © Mpirical Limited, 2021 15

 VoLTE Initial Procedures

 Service Route – this will contain the URI of the S-CSCF and is used for
future session establishment procedures. In particular, the contents of
this field will be placed in the Route: header of a service request to
ensure that the request is sent to the S-CSCF to which the subscriber
device is currently registered.
 P-Associated URI – if implicit registration is in use, this header field will
list the IMPUs that have additionally been registered as part of this one
registration procedure. This is particularly relevant when a temporary
Public ID has been used for registration, since this field will contain the
actual Public IDs the device must use for session establishment.

6.1 Third Party Registration

As part of the final stages of the registration process, several third party
registrations take place. These are triggered by the ifc associated with the
service profiles downloaded from the HSS to the S-CSCF. In essence, the AS
identified in a service profile will be the AS to which the registration is sent. As
a result, the AS will know that a particular IMPU is registered for service, and
it will also know which S-CSCF the IMPU is registered with.

Service profiles ,
including supporting
HSS ASs, sent in SAA
AS

REGISTER

S AS
CSCF

REGISTER

Figure 30 Third Party Registration

Registration Event Subscription

Registration in the IMS is an ongoing process, in that the user will remain
registered through a process of reregistration until the point at which they
deregister from the network. If at any point the user's registration expires,
deregistration from the network will take place.
However, there will be instances when the network forces a deregistration to
take place. An example of this could be that the S-CSCF with which the UE is
currently registered may need to be taken offline for a software upgrade. In
this case, the network would need to deregister all the users associated with
that S-CSCF. Obviously, in order to continue accessing their services, the
users would then be required to register again, the result of which would be
the allocation of a new S-CSCF. Eventually, all users will migrate away from
their original S-CSCF, allowing the service provider to take it offline.
The problem with this scenario is that the normal registration process is one
sided, in that the UE is the device that initiates the registration. If the network
initiates the deregistration, there is no way to inform the IMS terminal through
normal means. As such, it is not uncommon to see IMS terminals subscribing
to their own "Register Event" in order to keep informed as to the status of their
registration.
Subscription to the register event uses the SUBSCRIBE and NOTIFY
methods.

16 © Mpirical Limited, 2021 MPI0126-000-010

VoLTE Initial Procedures

Domain 1

S
CSCF
IMS Application
Subscriber Server 1

IMS Registration Process

SUBSCRIBE
SUBSCRIBE
To: IMSSubscriber 1@domain 1
From :IMSSubscriber 1@domain1 To: IMSSubscriber1@domain 1
Event : reg From:appserver 1@domain 1
Event: reg
200 OK
200 OK

NOTIFY NOTIFY

Registration State = active Registration State = active

200OK 200OK

Network
Initiated
Deregistration

NOTIFY NOTIFY

Registration State = Registration State =

terminated terminated
200OK 200OK

Figure 31 Register Event Subscription

As can be seen in Figure 31, the process begins with a normal registration
procedure. Assuming this is successful, the IMS terminal will then generate a
SUBSCRIBE method, which includes the Event: header field being set to reg.
On receipt of the SUBSCRIBE, the S-CSCF will NOTIFY the terminal as to
the current registration status. The body of this NOTIFY will contain an XML
document, in which the registration state is set to "active".
As shown in Figure 31, users are not the only entities that can subscribe to a
registration event. Application Servers will also typically subscribe, since they
too need to be aware of whether a user is registered with the system. The
principle of operation is still the same, although the From: fields will obviously
differ.
If at any point the network initiates a deregistration, any watchers (in this case
the IMS terminal and an application server) will be notified. This time, the
registration state will be set to "terminated".

Service Configuration (Ut Interface)

When an IMS subscriber is permitted to use a particular IMS service, it is
possible that that service may be configured with subscriber specific
information or preferences. Although the HSS (Home Subscriber Server) can
provide subscriber related information to an AS (Application Server), it is also
possible for the UE (User Equipment) to provide configuration information
directly to the AS via the Ut interface.

MPI0126-000-010 © Mpirical Limited, 2021 17

 VoLTE Initial Procedures

The Ut interface is based on XCAP (XML Configuration Access Protocol)3, as

shown in Figure 32. XCAP will allow the UE to read, write and modify XML
(eXtensible Markup Language) based application configuration data held on
the AS. To achieve this, the XCAP client in the UE will exchange HTTP (Hyper
Text Transfer Protocol) requests with the XCAP server within the AS.

Figure 32 Service Configuration via Ut Interface

As can be seen in Figure 33:

 Configuration data is read using a HTTP GET.
 Configuration data is written/modified using a HTTP PUT.
 Configuration data is removed using a HTTP DELETE.

Figure 33 Manipulating the XML Document using HTTP Commands

In order to amend XML based information using XCAP, XML sub-trees and
element attributes are mapped to HTTP URIs. Therefore, these components
can be directly accessed and ultimately manipulated via HTTP. Due to the
security risks associated with configuration data manipulation, it is possible
that authentication is involved in the configuration process.
Each application that makes use of XCAP specifies an application usage. This
application usage defines the XML schema for the data used by the
application, along with other key pieces of information. Application usages
designed for general use on the Internet are registered with the IANA, which
may mean that IMS orientated application usages are not registered (since
they are not designed for general Internet use). Figure 34 shows a selection
of application usages, which are identified with an AUID (Application Unique
ID).

3
RFC 4825 - The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)

18 © Mpirical Limited, 2021 MPI0126-000-010

VoLTE Initial Procedures

Figure 34 XCAP Application Usages

MPI0126-000-010 © Mpirical Limited, 2021 19

 VoLTE Initial Procedures

Glossary

AK (Anonymity Key) ISIM (IMS Subscriber Identity Module)

AKA (Authentication and Key Agreement)
AMF (Authentication Management Field)
APN (Access Point Name)
AS (Application Server)
AUID (Application Unique ID)
CK (Cipher Key)
HOS (Home Operated Services)
HSS (Home Subscriber Server)
HTTP (Hyper Text Transfer Protocol)
IK (Integrity Key)
IMSI (International Mobile Subscriber
Identity)
K (Subscriber Authentication Key)
NAS (Non Access Stratum)
PCO (Protocol Configuration Options)
RCS (Rich Communication Services)
SQN (Sequence Number)
UE (User Equipment)
XCAP (XML Configuration Access
Protocol)
XML (eXtensible Markup Language)
XRES (Expected Response)

MPI0126-000-010 © Mpirical Limited, 2021 21

Innovating Telecoms Training

Contact Us
Tel: +44 (0) 1524 844669
Email: enquiries@mpirical.com

www.mpirical.com