Page 357 - From GMS to LTE

VoLTE, VoWifi and Mission Critical Communication 343

Once the IMS LTE bearer is in place, SIP messages can be sent and received. In addition
to the previously described SIP registration procedure, further actions are necessary in
the IMS system. To be flexible, no IP configuration of the P‐CSCF system is necessary
in the device as it was informed of the IP address(es) of the P‐CSCF during the IMS
default bearer activation described above. In addition, the network informs the device
during the attach process and also later on during routing and tracking area update
procedures whether the current radio network supports IMS services. Thus it is possi-
ble, for example, to only offer IMS voice services while the mobile device is in the LTE
network and to instruct a device to use circuit‐switched services (cp. Chapter 1) for
voice calls while in the UMTS or GSM network of the same network operator.
Like in other parts of the network, the IMSI (International Mobile Subscriber Identity)
is used to identify a user. As the IMSI is stored on the SIM card it is not necessary to
manually configure it in the device.
To secure the transmission of signaling messages between a device and the P‐CSCF, a
security context is established during SIP registration based on the secret key Ki and
authentication algorithms stored on the SIM card, which are also used for authentication
in GSM, UMTS and LTE. An integrity checksum is included in all messages to ensure they
have not been modified accidentally or on purpose. Optionally, the signaling messages
between the mobile device and the P‐CSCF can also be encrypted. Figure 5.6 shows how
the IMS registration process is performed between the mobile device and the network.
Like in the fixed‐line SIP example above, the first message the mobile device sends is
a SIP Register message. Important parameters in the message are the IMSI, supported
authentication and ciphering algorithms, the device’s model name, its software version,
its serial number (IMEI, International Mobile Equipment Identity) and which IMS ser-
vices it supports. Typically, VoLTE devices support the MMTel service for voice teleph-
ony and SMS over IMS. In addition the message contains the identity of the IMS system
to be contacted. The name is built from the Mobile Country Code (MCC) and Mobile
Network Code (MNC) of the subscriber’s home network, e.g. ‘ims.mnc002.
mcc262.3gppnetwork.org’ and is used by the P‐CSCF in a DNS lookup to find the IP
address of the entry point into the IMS system.
When the S‐CSCF receives the message it uses the IMSI to find the subscriber’s
record in the Home Subscriber Server (HSS) and sends a ‘401 Unauthorized’ message
back to the subscriber with an authentication challenge. This challenge is forwarded by
the mobile device to the SIM card, which creates a response and the parameters required
to set up an IPSec security context between the mobile device and the P‐CSCF. If
required by the network, the data is encrypted. Otherwise the IPSec tunnel is used only
for protecting the integrity of the message, which is mandatory. It should be noted at
this point that the use of IPSec to encapsulate the SIP signaling traffic is specific to
wireless IMS.
If the response to the S‐CSCF was correct the network considers the device to be
properly authenticated and responds with a SIP ‘200 OK’ message. In addition the
S‐CSCF downloads the subscriber’s IMS profile from the HSS, which contains informa-
tion about which other nodes in the network to inform of the successful registration. In
the case of VoLTE, the Telephony Application Server (TAS) that implements the MMTel
functionality wants to be informed of the successful registration.
In a final step the mobile device now subscribes to the registration notification event.
These events can be sent by the network to the device after registration when the