IMS  

 

 

 

Check List

I think I have been involved in tesing IMS features running on UE since early 2012.. at the beginning there were no UE with embedded IMS stack even though every body were talking about IMS. so started with independent IMS client software runnning on the phone like IMSDroid. and as far as I remember, from around mid 2012 I started seeing UEs with its own IMS stack. Considering this, I thought I had pretty long experience with IMS testing and studying various IMS issues.

However, I am still not so confident on this topics. Unfortunately, the more experience I think I have obtained, the less confident I am.

I wish I had some standard/clear methods or procedure to troubleshoot IMS issue and can share the list with readers, but unfortunately I don't think I can come out with such troubleshoot tips.

However, I think it would still be helpful to come up with some of useful questions that might help you to solve various IMS issues. I don't have any clear answers to all of these questions. The reason is not because there is no answer to these question but because there can be MANY answers depending on the situation and implemenation of the IMS stack.

My recommendation is to make your own answer key for each of these questions before you do any IMS testing. You may revise your answer key when the stack developer modifies the implementation and add features, meaning that the answer key created a month ago may not be the correct answer to the IMS stack you are to test today.

The list of check items would vary depending on which step UE call status is at. I put some of my personal check list for various call status.

1. Check before SIP : REGISTER

One of the most common problem and at the same time the trickest problem is "you power on UE and saw UE successfully camped on to LTE network and you are waiting for UE to initiate IMS registration but nothing happens. You don't see any SIP : REGISTER message being sent by UE."

The most common strategy for any kind of troubleshooting is to collect UE log and trying to find something. But problem is that most of logging would not provide much information to help troubleshoot at this stage and you would not get any hints from Network side log since you would not see anything on network log. This is why I said this problem would be one of the trickest thing to troubleshoot. Most of the critical information at this stage tend to hide in the source code of the protocol stack and would not get printed out in trace log. Therefore, I think the best strategy for the troubleshoot at this stage is to communicate with IMS stack developer and make your own list of 'Precondition for sending SIP : REGISTER'. Following is some of my personal list that may help you. Some of these items may not sound relavent to the problem, but I personally have seen the issues related to each and every items listed below.

Check Point/Question

Comments

1.1 How many PDN should be established before SIP : REGISTER ?

 

1.2 For each PDN, is there any specific APN name required or any APN name is allowed ?

 

    1.2 a) if there is APN Name Requirement, make a list of APN Name for each PDN

 

1.3 For each PDN, is there any specific IP version requirement ?

(IPv4 only, IPv6 Only, IPv4v6, or anything ?)

 

1.3 For each PDN in which IPv6 is allowed or required, what would happen if Router Discovery (Router Solicitation, Router Advertisement) fails ? (The most common behavior is that UE initiate Detach process for the PDN)

 

1.4 For each PDN in which IPv6 is allowed or required, does UE require any specific 'Network Prefix' address ? or is any 'Prefix' acceptable ?

 

    1.4 a) When UE is establishing multiple IPv6 PDN (for example 3 PDN, one for internet, one for normal IMS and one for PSAP), does each of PDN requires separate 'Network Prefix' address which are different from each other ?

In most of the device, it doesn't seem that UE require separate Prefix, but recently (as of Mar 2017) I see some device require separate Prefix for each PDN.

1.5 For each PDN in which IPv6 is allowed or required, does UE require any specific Interface Identifier in NAS message ? or Is Any Interface Indentifier OK ?

 

1.6 In case of IPv6, how UE allocate its Network Prefix ?

(In most case, it is expected for UE to get this part from Router Advertisement.. but you need to clarify on this)

 

1.7 In case of IPv6, how UE allocate its Interface Identifier ?

(In most case, it is expected for UE to get this part from PCO, but some UE allocate random value or MAC address based value. Sometimes non-PCO based Interface ID cause problems)

 

1.8 For each PDN, is there any specific requirement for Activate default EPS bearer context request.eps_netwk_feature_support ?

 

    1.8 a) if there is any feature Requirement, make a list of the requirement for each PDN

 

1.9 For each PDN , is there DNS query that must be replied to allow IMS service ?

 

    1.9 a) if there is any DNS Requirement, make a DNS Table

 

1.10 What does UE do if it does not get any of the information it requested at PCO in PDN Connectivity Request ?

 

1.11 Is there any specific PLMN requirement ?

 

1.12 How does UE gets CSCF address ? (From PCO from NAS message ? or UE internal Configuration setting)

 

1.13 How does UE gets CSCF domain name ? (From ISIM ? or from UE internal Configuration ?)

 

1.14 Is ISIM Required ?

 

 

1.15 Is GBA Required ?

 

2. Check right at the REGISTER

If you cleared up every items in previous check list, UE is supposed to send REGISTER message (If IPv6 is required for IMS, the IPv6 allocation procedure should be complete as well before UE send REGISTER. I saw many cases where UE just close IMS PDN not because of SIP parameter issue but because it failed in IPv6 allocation procedure).

There are many important information in sip REGISTER message. You have to clearly understand how your UE get those information and populate into REGISTER message. Followings are the check list at this stage.

Check Point/Question

Comments

2.1 How UE get item (1), i.e, the request uri of REGISTER message ?

The most common method is to get it from ISIM (Refer to ISIM and User ID page), but in many case ISIM may have only some of them, not all of them (especially the test ISIM). Then the question is how UE to get those missing information that is not specified in ISIM.

2.2 How UE get item (2) ?

2.3 How UE get item (3) ?

2.4 How UE get item (4) ?

2.4 How UE get item (5) ?

    REGISTER sip:(1)test.3gpp.com SIP/2.0

    f: <sip:(2)001010123456789@ims.mnc246.mcc081.3gppnetwork.org>;tag=2922225

    t: <sip:001010123456789@ims.mnc246.mcc081.3gppnetwork.org>

    CSeq: 2922203 REGISTER

    i: 2922206_181933240@2001:0:0:1::3

    v: SIP/2.0/TCP [2001:0:0:1::3]:5060;branch=z9hG4bK3941737881

    Max-Forwards: 70

    m: <sip:001010123456789@[2001:0:0:1::3]:5060>;

                      +sip.instance="<urn:gsma:imei:35425006-000655-0>";

                      +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";

                      +g.3gpp.smsip

    Route: <sip:[2001:0:0:1::2]:5060;lr>

    l: 0

    Authorization: Digest uri="sip:(3)test.3gpp.com",

                        username="(4)001010123456789@test.3gpp.com",

                        response="",

                        realm="(5)test.3gpp.com",

                        nonce=""

    Expires: 600000

    Require: sec-agree

    Proxy-Require: sec-agree

    k: path,sec-agree

    Allow: INVITE,BYE,CANCEL,ACK,NOTIFY,UPDATE,REFER,PRACK,INFO,MESSAGE,OPTIONS

    Security-Client:

                   ipsec-3gpp; alg=hmac-md5-96; ealg=des-ede3-cbc; spi-c=799251570; spi-s=1387593208;

                                    port-c=8006; port-s=8906,

                   ipsec-3gpp; alg=hmac-md5-96; ealg=aes-cbc; spi-c=799251570; spi-s=1387593208;

                                    port-c=8006; port-s=8906,

                   ipsec-3gpp; alg=hmac-md5-96; ealg=null; spi-c=799251570; spi-s=1387593208;

                                    port-c=8006; port-s=8906,

                   ipsec-3gpp; alg=hmac-sha-1-96; ealg=des-ede3-cbc; spi-c=799251570; spi-s=1387593208;

                                    port-c=8006; port-s=8906,

                   ipsec-3gpp; alg=hmac-sha-1-96; ealg=aes-cbc; spi-c=799251570; spi-s=1387593208;

                                    port-c=8006; port-s=8906,

                   ipsec-3gpp; alg=hmac-sha-1-96; ealg=null; spi-c=799251570; spi-s=1387593208; port-c=8006;

                                    port-s=8906

3. Check right after SIP : REGISTER

Once you ensured everything in step 1 and your UE always tries 'SIP : REGISTER' every time you power cycle the device, next step is to complete the whole Registration process. When I first started tesing with IMSDroid, everything was so simple at this stage. As long as NW accept the REGISTER from UE and send 200 OK, everybody (NW, UE and myself :) ) was happy and Registration is complete ! However, as time goes on, more and more factors kicks in the registration process and accordingly more and more problems that we have to troubleshoot. Followings are some of the common factors and the source of the problems during the registration.

Check Point/Question

Comments

3.1 Does UE require 'Authentication' ?

 

    3.1 a) if Authentication is required, make a list of Authentication Parameters

See Example

3.2 Does UE require IPSec ?

 

    3.2 a) if IPSec is required, make a list of IPSec Parameters (e.g, Algorithm etc)

See Example

3.3 Does UE require specific SUBSCRIPION/NOTIFICATION ?

See Example

    3.3 a) if SUBSCRIPION/NOTIFICATION  is required, make a list of Event type

 

3.4 Does UE require 'Precondition' ?

 

4. Check for VoLTE Service

Once you completed the full registration process, a natural next step is to try VoLTE. Usually I don't see many problem in VoLTE once the device successfully complete the registration process, but still there are some important steps that needs to be clarified as listed below.

Check Point/Question

Comments

4.1 Does UE has any specific 'Port Number' (UDP or TCP port) requirement for SIP message ?

 

4.2 What the UE would do when it get INVITE (for VoLTE) when it is registered without Authentication ?

Most of UE take the VoLTE call, but I saw some UE rejecting the call.

4.3 What the UE would do when a user dials number and press [Call] button when it is registered without Authentication ?

Most of UE initiate the VoLTE, but some UE does not send SIP INVITE for VoLTE.

4.4 Does UE require 'Precondition' ?

 

3.5 Does UE send PRACK ?

 

    4.5 a) if UE send PRACK, does it send always with SDP ? or send SDP optionally ?

 

    4.5 b) if UE send SDP in PRACK optionally, what is the conditon for sending SDP ?

 

    4.5 c) if UE does send SDP in PRACK, is it still expecting UPDATE procedure ?

See This Comments

4.6 Is there any specific requirement in SDP ?

 

    4.6 a) if there is a requirement in SDP, make a list of all the requirement

 

5. IMS Setup Process with IPv4

Following is sequence mainly from Power on to REGISTER message. From REGISTER, you can use typical troubleshooting technique using Wireshark.

    1) Power-On UE

    2) Initiate Access Network Registration (e.g, LTE Registration)

    3) UE -> NW : PDN Connectivity Request (for IMS PDN)

      Check : UE send the Information it needs (e.g, DNS, CSCF IP address etc) via PCO

    4)UE <- NW : Activate Default EPS Bearer Context Request (for IMS PDN)

      Check : NW send UE IP and the information that UE requested via PCO

    5) UE -> NW : Activate Default EPS Bearer Context Accept

      Check a) : In UE log or UE GUI, check if UE assigned its IP based on the IP allocated at step 4).

      Check b) : Ping between UE and Server

      Check c) : UE got all the other informations that is required to initiate IMS Registration

              (e.g, CSCF Address, ISIM Parameters etc)

    6) UE IMS Stack -> UE SIP Stack : REGISTER

    7) UE SIP Stack -> UE Radio Stack (PDCP -> PHY) : REGISTER

    8) NW Radio Stack (PHY -> PDCP) -> NW SIP Stack : REGISTER

    9) NW SIP Stack -> NW IMS Stack : REGISTER

6. IMS Setup Process with IPv6

Following is sequence mainly from Power on to REGISTER message. From REGISTER, you can use typical troubleshooting technique using Wireshark.

    1) Power-On UE

    2) Initiate Access Network Registration (e.g, LTE Registration)

    3) UE -> NW : PDN Connectivity Request (for IMS PDN)

      Check : UE send the Information it needs (e.g, DNS, CSCF IP address etc) via PCO

    4)UE <- NW : Activate Default EPS Bearer Context Request (for IMS PDN)

      Check : NW send UE IPv6 'Interface ID' and the information that UE requested via PCO

    5) UE -> NW : Activate Default EPS Bearer Context Accept

    6) UE -> NW : Router Solicitation

    7) UE<- NW : Router Advertisement with Network Prefix

      Check a) : In UE log or UE GUI, check if UE assigned its IPv6 based on the IP allocated at step 4) and 7).

           The expected IPv6 address in UE is as follows :

          Interface ID : The one allocated by Activate Default EPS Bearer Context Request

          Network Prefix : Network Prefix allocated by Router Advertisement

      Check b) : Ping between UE and Server

      Check c) : UE got all the other informations that is required to initiate IMS Registration

               (e.g, CSCF Address, ISIM Parameters etc)

    6) UE IMS Stack -> UE SIP Stack : REGISTER

    7) UE SIP Stack -> UE Radio Stack (PDCP -> PHY) : REGISTER

    8) NW Radio Stack (PHY -> PDCP) -> NW SIP Stack : REGISTER

    9) NW SIP Stack -> NW IMS Stack : REGISTER

7. RCS Triggering (Initiation) Condition

To be honest, it is not easy for me to describe about the common condition for RCS initiation (Triggering) as of now (Jul 2017).  This difficulty is not coming from technical issue. It is mainly coming from the lack of common agreement between service providers and UE manufacturer. I think it will take at least a couple  of more years until we see some common requirement for RCS. We have see IMS development / deployment activities in LTE at least 5 years or more, but only recently we got to have some 'conformance' test in 3GPP, which means a common requirement in 3GPP area. I think RCS would go along with similar path. In worst case, we would never see any common implementation of RCS.

I think the part that differetiate the RCS implementation most critically is the triggering (initiation) condition of RCS. This would make RCS testing extremly difficult especially when you want to test it with test equipment.

Followings are some of the triggering condition that I have seen from several different devices for several different carriers (All of these are based on the assumption that the conditions for IMS registration is already met). If you are trying to test a RCS device, you have to know which of the following conditions are required to enable RCS features in UE(DUT)

    1) PUBLISH message during IMS registration : In some device, if UE gets the proper (expected) response from test equipment for PUBLISH message and the device allows RCS operation.

    2) Capability discovering with OPTION message : Some device requires Device (UA) capability using OPTION message.

    3) Capability discovering with SUBSCRIBE / NOTIFY : Some devices require special SUBCRIBE / NOTIFY process before it allows any RCS operation.

    4) Capability / Configuration setup via Autoconfiguration : Autoconfiguration is a process (mechnism) by which UE get access to a special server (ACS : Auto Configuration Server) and retrieve all the configuration from the server. This transaction usually requires special security mechanism (e.g, SSL) and security information (e.g, Certification info). If you want to try RCS with a test equipment (not live network) and UE requires this feature, this would be the most difficult situation for you.