4G to IMS call flow – Register to IMS – part 4

Posted: August 29, 2010 in technical
Tags: , , , , , , , , , , , , , , , , ,

As I was saying in part 3: let’s get down to business 🙂
The 4G portion of the 4G – IMS registration has been described in Part 1;
The IP-CAN Session Establishment has been described in Part 2;
The generic IMS specifications (at least part of them) have been described in Part 3;

Now, let’s analyze the messages from the IMS – SIP signaling. As I was saying, these messages are tunneled between the eNodeB and PGW via GTPv1-U protocol. Then they reach the P-CSCF and are forwarded in the IMS core. This P-CSCF entity, often called simply P, can be located – and usually it is, specially in the roaming scenarios, … located in the visited network.

Before continuing to the description of each of the messages in the IMS registration, let’s take another look at the 4G – IMS architecture, as well as to the registration flow that we describe:

4g-ims

4G-IMS Architecture

4G-IMS RegistrationFlow

4G-IMS

16. P-CSCF Discovery

– described in TS 23.228: section 5.1.1 Procedures related to Proxy-CSCF discovery and

section E.1.1.1 GPRS/EPS procedure for P-CSCF discovery

Because the procedure is pretty straight-forward, I will just copy-paste it from the spec above:

The Proxy CSCF discovery shall be performed using one of the following mechanisms:
– As part of the establishment of connectivity towards the IP-Connectivity Access Network, if the IP-Connectivity Access Network provides such means.
Alternatively, the P CSCF discovery may be performed after the IP connectivity has been established. To enable P CSCF discovery after the establishment of IP connectivity, the IP-Connectivity Access Network shall provide the following P CSCF discovery option to the UE:
Use of DHCP to provide the UE with the domain name and/or IP address of a Proxy CSCF and the address of a Domain Name Server (DNS) that is capable of resolving the Proxy CSCF name, as described below in clause 5.1.1.1.
The UE may be configured (e.g. during initial provisioning or via a 3GPP IMS Management Object (MO), TS 24.167 [64] or in the ISIM, TS 31.103 [69]) to know the fully qualified domain name (FQDN) of the P CSCF or its IP address. If the domain name is known, DNS resolution is used to obtain the IP address.
In the case where UE is aware of more than one P CSCF address, the selection shall be based on home operator configured policy to select the P CSCF.
NOTE:Subject to home operator policy, the UE selects the Home P CSCF to be used by either using a pre-configured Home P CSCF FQDN or according to TS 24.167 [64]. This can be done without the UE first performing the local P CSCF discovery (e.g. DHCP).

Section 5.1.1.1 describes the DHCP/DNS procedure for P-CSCF discovery:

The DHCP relay agent within the IP-Connectivity Access Network relays DHCP messages between UE and the DHCP server.

p-cscf-dhcp-dns

1.Establish an IP-Connectivity Access Network bearer if not already available by using the procedures available in the IP-Connectivity Access Network.

2.The UE requests a DHCP server and additionally requests the domain name and/or IP address of the P‑CSCF and IP addresses of DNS servers. It may require a multiple DHCP Query/Response message exchange to retrieve the requested information.

3.The UE performs a DNS query to retrieve a list of P‑CSCF(s) IP addresses from which one is selected. If the response does not contain the IP addresses, an additional DNS query is needed to resolve a Fully Qualified Domain Name (FQDN) to an IP address.

After reception of domain name and IP address of a P‑CSCF the UE may initiate communication towards the IM subsystem.

Section E.1.1.1 describes the GPRS/EPS procedure for P-CSCF discovery

I will just show the 4G part, procedure valid for both E-UTRAN Initial Attach procedure, as well as for subsequent PDN Connectivity Requests:

p-cscf-eps-bearer

1.   During Initial Attach/PDN Connection Request, the UE indicates that it requests a P‑CSCF IP address(es).

2.   The MME sends a Create Default Bearer Request to the S‑GW.

3.   The S‑GW forwards the request to the P‑GW and the P‑GW gets the IP address(es) of the P‑CSCF(s). The mechanism to do this is a matter of internal configuration and is an implementation choice.

4.   If requested by the UE, the P‑GW includes the IP address(es) of the P‑CSCF(s) in the Create Default Bearer Response.

5.   The S‑GW forwards the response to the MME

6.   Completion of procedures, as described in TS 23.401 [70].

After reception of the IP address of a P‑CSCF the UE may initiate communication towards the IM CN Subsystem.

17. Register message sent from the IMS terminal to the P-CSCF

Once the IMS terminal obtains its IP address, it must register to the IMS network. This happens in order for the UE to authenticate and obtain authorization to use the IMS network resources. The IMS registration is accomplished by the SIP REGISTER message – this being also the only SIP message that is authenticated by the network (subsequent SIP messages, like INVITE, 200 OK…and so on, are not being authenticated).

First of all, we should know that the IMS-SIP is a SIP (RFC 3261) on steroids (as my SIP colleague use to joke 😛 ), because it has a lot of 3GPP enhancements to meet the 3GPP requirements for this type of communication – I won’t get into details right now. One requirement is that, in IMS, unlike in regular SIP, a phone cannot make any call without first being registered to the IMS network.

Second of all, let’s establish the meaning of this “register” procedure. What the REGISTER procedure does is bind the public URI of that IMS user to a certain IP address and/or host name. The IP address/host name are the ones given by the IP-CAN Session during attach or later on. It is the means of locating that phone in the network. The point is to let the IMS network know at which actual address (IP/host name) it can find a user it has configured as subscriber.

Short note: this public URI thinggie is the identity of the subscriber, something like an e-mail address, only less pretty :P. It can also contain a bunch of weird parameters that I won’t get into details with right now:

examples of SIP URIs:

sip:Alice.Smith@domain.com

sip:Bob.Brown@example.com

sip:carol@ws1234.domain2.com;transport=tcp

SIP URIs with SDP information (SDP – Session Description Protocol) :

v=0

o=Bob 234562566 236376607 IN IP4 192.0.0.2

s=Let’s talk about martial arts

c=IN IP4 22.22.22.22

t=0 0

m=audio 30000 RTP/AVP 0

a=sendrecv

m=video 30002 RTP/AVP 31

a=sendrecv

Before actually taking a look at this fancy SIP REGISTER message, let’s present the IMS requirements for SIP Registration:

[Bear in mind that many of the information below are inspired/taken from the following book:

http://www.amazon.com/3G-IP-Multimedia-Subsystem-IMS/dp/0470871563

The 3G IP Multimedia System: Merging the Internet and the Cellular Worlds

by Gonzalo Camarillo and Miguel-Angel Garcia-Martin ]

The IMS registration procedure satisfies the following requirements in two round trips:

(a) the user binds a Public User Identity to a contact address – this is the main purpose ofa SIP REGISTER request;

(b) the home network authenticates the user;

(c) the user authenticates the home network;

(d) the home network authorizes the SIP registration and the usage of IMS resources;

(e) in case the P-CSCF is located in a visited network, the home network verifies that there is an existing roaming agreement between the home and the visited network and authorizes the usage of the P-CSCF;

(f) the home network informs the user about other possible identities that the homenetwork operator has allocated exclusively to that user;

(g) the IMS terminal and the P-CSCF negotiates the security mechanism that will be in place for subsequent signaling;

(h) the P-CSCF and the IMS terminal establish a set of security associations that protect the integrity of SIP messages sent between the P-CSCF and the terminal;

(i) both the IMS terminal and the P-CSCF upload to each other the algorithms used for compression of SIP messages.

Before creating the SIP Register message, the UE terminal retrieves the Private User Identity from its ISIM card, along with its Public User Identity and its home network domain URI.
OK, so let’s take a look at the actual SIP REGISTER message the IMS terminal sends to its P-CSCF, via the 4G Access Network:
REGISTER sip:registrar1.home.net SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bK9h9ab
Max-Forwards: 70
P-Access-Network-Info: 3GPP-EUTRAN-FDD;eutran-cell-id-3gpp=C359A3913B20E
From: <sip:alice_public@home.net>;tag=s8732n
To: <sip:alice_public@home.net>
Contact: <sip:[5555::aaa:bbb:ccc:ddd];comp=sigcomp>;expires=600000
Call-ID: 23fi57lju
Authorization: Digest username=”alice_private@home.net”,realm=”registrar1.home.net”, nonce=””,uri=”sip:registrar1.home.net”, response=””
Security-Client: ipsec-3gpp; alg=hmac-sha-1-96;spi-c=3929102; spi-s=0293020; port-c:3333; port-s=5059
Require: sec-agree
Proxy-Require: sec-agree
Cseq: 1 REGISTER
Supported: path
Content-Length: 0
1. The first line identifies the method, which is REGISTER, then it is followed by the Request-URI. This Request-URI identifies the destination domain of the Register request.
– this Request-URI has the role of registration URI which identifies the home network or a subdomain of the network
2. The Via header is the IP address ( here: 5555::aaa:bbb:ccc:ddd) given to the UE during the initial attach or bearer activation, statically or dynamically (IP-CAN) assigned.
3. The P-Access-Network-Info represents the access type and information related to the access network, in our case, a 3GPP 4G network – LTE wireless, FDD, with the specified cell id.
4. The To: and From: fields are usually taken from the USIM. These fields have the same value in the Register message, representing the Public User Identity, also called Address-of-Record. This is the identity the other parties know and use to contact this UE.
5. The Contact: header represents the temporary point of presence for this UE. Its value is the most recent IP address the UE has and this address is stored in the S-CSCF. This is the third important parameter about the UE, the Contact Address (the other two being the registration URI and Address-of-Record).
6. The Authorization field caries out authentication information about the terminal. This information is the forth parameter used for registration, having the role of the Private User Identity. This value is the equivalent of the IMSI field in the GSM system and it should not be displayed to the user. It is used by the AKA fields to authenticated the user. This parameter is composed by the private ID and the domain name of the home network where the UE registers.
The nonce and response parameters are empty, because this case considers the terminal has just been turned on for the first time, otherwise there should have been some cached information to send here.
7. The Security-Client field lists the algorithms supported by the UE. In this case, the terminal has IPsec capabilities.
8. The client requires the parties to agree on its security parameters and also indicates it supports the Path header.
Before moving on to the DNS query functions of the P-CSCF, we should know that usually the P-CSCF is not located in the same network as the home network of the UE. This is why it is very possible it does not have an entry point into the user’s home network. Still, in order to be able to serve this UE, the P uses information from the user in order to locate the I-CSCF from the home network. This procedure is a DNS query specified in RFC 3263 and its purpose is to give this P a SIP URI of the home network I. After the P locates this I, it will forward the REGISTER message to the I, inserting along a P-Visited-Network-ID header that identifies the location (domain name of the network) of the P.
This P-Visited-Network-ID is necessary so that the home network verifies it actually has a roaming agreement with the visited network. Also, the P-CSCF inserts its own SIP URI into the Path header, so that the I-CSCF knows where to forward the reply. It is important that the Path header is populated, so that every request from the home network is forwarded via this P-CSCF visited network proxy, otherwise the requests will never reach our roaming subscriber.
— the DNS query procedures in the next episode —
Advertisements
Comments
  1. Saurabh says:

    Many Thanks Bro,
    I appreciate your clarity about the concepts, that led you achieve simplicity while describings lots of concepts concurrently.
    I referred you as Bro, cos I am writing by my heart, not by my technical brain. I am overwhelmed 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s