IMS

  

 

 

 

IMS / SIP Testing

 

As far as I recall back from now (Feb 2017), the time when I tried SIP based testing (pretty much from my personal interest at that tiime) was sometime in 2010. At that time, the only available LTE device I could get were a few data card (see LTE UE page). What motivated me to get interested in IMS/SIP at the time were based on following.

  • LTE is data only communication with no Voice Call capability. So it would need some other technique to provide Voice Call Service
  • CSFB(CS Fallback) will be the first phase Voice Call solution for LTE, but this will be only an iterim solution.
  • Eventually IMS/SIP based Voice Call solution will be the major solution for Voice call service in LTE

I want to summarize the history of IMS/SIP testing in relation to LTE network in this page and this is mainly based on my personal experience. Some of the testing method would be considered to be too out-dated from today's perspective (as of Feb 2017) and may not be used any more, but I will still keep those old method described in this page to give you some insight on how this technology has been evolved. Followings are the topics to be covered in this post.

 

 

Setting up a SIP test environment - 2 PCs

 

This was what I tried sometime in 2010 (if I remember correctly) but I haven't used this configuration since I got the first Smartphone based IMS client called 'IMS Droid' and some IMS Server that can run in connection to LTE network simulator. However, if you are not working in this industry it would not be easy to get access to LTE network simulator because those equipments are too expensive to get it as a hobbiest or as a student. So this kind of configuration would still be a useful tool for many people.

 

For a long time (in 2010), I have been looking for a small scale server which is free and can be installed on my PC so that I can have some hands-on experience. As in any learning process, I would never fully understand it without doing it myself, coming across various problems, pulling the hair and asking around every person I know and eventually solving the problems.

After a long waiting and searching, finally I found a handy SIP application server that meets all of my requirements.

The test configuration that I setup is as follows. (For any IP related test, try this kind of two PC test and get familiar with operation/mechanism/troubleshooting first before you try with your mobile device (DUT)).

 

 

The software package that I used "3CX Phone System" and you can get it from following links.

 

3CX Phone System Download : http://www.3cx.com/phone-system/

3CX Phone Download : http://www.softpedia.com/get/Internet/Telephony-SMS-GSM/3CX-VOIP-Phone.shtml

YouTube Introductions :

      i) Installing 3CX MyPhone desktop components

 

To enable 3CX Phone System to support VoIP call functionality, you need to purchase a license. But you can use the demo license which will be emailed to you after you download the software. The demo license allows VoIP call between only two phones, but it is good enough for this kind of testing. (You can use 'chat' services between clients even without the license).

 

Installation is pretty straight forward, but setting all the configuration may be a little tricky. If you email me, I can send you ppt slides showing all the configuration for my test setup.

 

Once you get this working, you can try various things like texting, VoIP and even Video call and capturing the IP traffic with Wireshark and these logs can be your text book.

 

 

Setting up a SIP test environment - LTE Network Simulator and LTE Device

 

Looking backwards, I think I have seen (mostly tried) various types of IMS/SIP test environment with LTE. These test setups appears to change in evolutionary mode rather than being used all at the same time. In this section, I will introduce you some of the possible test configuration. Most of them are what I have tried .. but some of them are not.

 

 

< Case 1 > 3CX Client - LTE Simulator - 3CX Server

 

This configuration is what I have tried for the first time some time in 2010 just to get some understanding on proof of concept on IMS/SIP, but I haven't used this configuration for a long time. So most of the details are already vapoured out of my memory.

 

Following shows the test setup with LTE Network Simulator and LTE Device. (In this case, I used the network interface created by the UE as SIP server port and I configured PDN IP address transmitted by the network simulator to be 192.168.1.231.

 

 

 

< Case 2 > 3CX Client on SmartPhone - LTE Simulator - 3CX Server

 

This is the setups that I haven't tried myself.  Recently (Feb 2017) after I got some questions from a reader on IMS/SIP test setup, I became curious that 3CX might have released Smartphone App client. Then, I googled and found there is one available from 3CX home page (See the page : Installing the 3CX Client for Android ). If this App works as I expected, following test setup would be possible.

 

 

 

< Case 3 > IMS Droid on SmartPhone - LTE Simulator - External Commercial Server

 

I think this is the first configuration that had been widely used at the very early stage of IMS/SIP testing. At that time, a lot of talks were around but none of the Smartphone has stable IMS stack and LTE Network Simulator vendors didn't have any mature IMS/SIP server. So in many case I have downloaded an Android App named 'IMS Droid' on UE side and I could get access to a commerical IMS/Server called 'ProLab' that were pretty widely used in the industry.

As time went on, some UE vendors start providing their own IMS stack (Native IMS client). If the Native IMS stack were stable enough (or at least testable) or configuration was flexible enough to enable us to tweak the UE configuration to match the equipment configuration, I used the Native IMS client as well.

 

 

 

< Case 4 > Native client on UE - LTE Simulator - Internal Server

 

As far as I see in LTE testing (UE testing) industry, this would be the most common test setup as of now (Feb 2017). Most of the main stream test equipment is now have their own IMS/SIP server installed within the equipment itself and 3GPP versions of IMS/SIP specification is getting pretty mature now. (At least to me, 3GPP specification looks much clearer than RFC or GSMA (IR specification) specificaiton). So for the past several years, I have used this configuration only.

 

 

 

< Case 5 > Native client on UE - LTE Simulator - Live Network Server

 

In case of IMS, a lot of detailed features are determined by the requirement from each Network Operators. So even if your device has passed in terms of 3GPP requirement, it is not guaranteed that it will work in carrier network without any problem. So some people especially acceptance engineer in Network Operator wants to hook up Radio Acess Network part of LTE Simulator to carrier's IMS core network. In this way, the engineer can have access to Radio Access Network over which they can have full control in terms of configuration and time and still test IMS part based on real network requirement.

 

 

 

< Case 6 > Native client on UE - LTE Pico/Femto Cell - Live Network Server

 

I saw a couple of companies are using this method to test IMS/SIP but I haven't tried this myself. In terms of end user's requirement, this would be the best test setup. They put the live network pico or femto cell in their lab and test their device using the real network. In this case you need to use USIM/ISIM provided by Network Operator and you cannot use ordinary Test USIM/ISIM. Another drawback with this kind of testing would be that you would not get access to Network Side log when you need to troubleshoot any problems and you would not be allowed to tweak any network parameters as you like.

 

 

 

IMS/SIP Testing - What are we testing ?

 

As for any other function, for IMS/SIP testing you can think of two different approaches. One is with Live Network and the other with Lab test equipment. In this section, I would only talk about the test with Lab test equipment, not with Live Air.

 

The most common Lab Test setup would be as shown below. You need an equipment which can emulate Radio Access Network/NAS and then connect the equipment to IMS Server/Test Engine.

As far as I know, most of current (as of Apr 2013) LTE network simulator (UE Test Equipment) have their own embedded IMS Server. But I haven't seen any of those embedded IMS server which is full-fledged to provide enough capability/flexibility to test all the detailed IMS/SIP features.

On the other hand, there is a couple of company who provide IMS Server/Test Engine which provides high flexibility and very side test capability, but these company does not provide their own Access Network/NAS emulator.

So ideally the best solution would be to combine a Access Network emulator from one company with IMS Server from another company, but in reality interfacing the two solution from two different companies would not be easy, even though it is not impossible.

 

 

< A Tip on Test Equipment Selection >

 

Theoretically, 'LTE Network Simulator' part should not be a critical factor as long as it has basic state machine alowing "UE to camp on and establish EPS bearer", but in practice it is not as simple as it sounds. It is mainly because there can be many different paths to 'EPS bearer establishment for IMS' and Each UE may require different variations of statemachine for the process. For example, some UE require only Default EPS bearer with IPv4, some UE would require the estabilishement of two default EPS bearer and use the second one for IMS and some other UE would require the establishement of one default and one dedicated EPS bearer and use the dedicated bearer for IMS.. there can be many other variations. So the LTE Network Simulator should have very flexible statemache. According to my experience, most of 'LTE Network Simulator' in the market falls into one of the following options.

 

Option 1 : Script or Statemachine Generation Tool based.

Option 2 : Call Box Based (Ready made statemachine)

 

In theory, it should be possible to implement any statemachine (however complex it is) with Option 1, but "be possible to do something" and "be easy (in practical sense) to do something" is different. Option 1 can be useful for creating test cases for radio stack only (e.g, those like 36.523) but it would be difficult for one or two persons to implement complicated statemachine for application test like IMS.

Usually Option 2 tend to provide more flexible (complicated) statemachine comparing to Option 1, so it can be a better fit for the application test. However, you have to verify the flexibility of the equipment before you decide to pick up since each equipment vendor supports different level of flexibility.

 

 

 

 

< General Test Methodology >

 

In terms of test methodology, there can be two levels of testing as listed below.

  • Entry level functionality test
  • Detailed protocol stack test
  • Media Quality Test/Analysis (e.g, Voice Quality, Video Quality test)

In Entry Level functionality test, you would try following things (I think most of Access Network Simulator Vendors are TRYING to provide all these functionality, even thought I haven't seen any equipment vendor which support all of these as of now (as of Mar,2013).

  • Turn on IMS functions on UE and see if IMS registration properly go through.
  • Send SMS over IMS and see if the message gets successfully delivered to the other party.
  • Make a Voice Call (VoLTE) from UE or from Test Equipment and see if the call is properly setup.
  • Make an Emergency Call (VoLTE) from UE or from Test Equipment and see if the call is properly setup

In IMS protocol stack test, thre can be an entry level and advanced level testing as well. In entry level testing, you can simply Ignore, Reject or Send Error messages as illustrated below and see how UE act in each of those cases. In advanced level, you would modify the IMS protocol state machine itself and teak each detailed parameters of each message and see how UE respond to each of those variations.

 

 

 

< Detailed Test Case for Registration - Normal Process>

 

Following is a typical IMS Registration procedure including some Radio Protocol which may be required to provide necessary information to UE for the Registration. I don't think Step 7)~10) are mendatory steps.. but I saw most of UE that I tested lately (as of Mar 2014) goes through these steps.

 

    1) UE <-- NW : RRC : RRC Connection Reconfiguration

                        + NAS : Attach Accept + NAS : Activate Default EPS Bearer Context Req

      • Usually network send CSCF address via PCO in this message. (Most network operator provide CSCF through this radio message, but there can be other possibility of informing UE of CSCF address. See CSCF Discovery for the details)
      • Check Point : Check if UE properly get the information from this and use it for IMS Registration at step 3)

     

    2) UE --> NW : RRC : RRC Connection Reconfiguration Complete

                        + NAS : Attach Complete + NAS : Activate Default EPS Bearer Context Accept

    3) UE --> NW : REGISTER

      • Check Item : Check if UE uses proper UE ID (Which UE ID to be used is determined by Service Provider)
      • Check Item : Check if UE does not set IPSec (In most case, UE should not set IPSec since this is before Authentication)
      • Check Item : Check if UE sets proper value for 'Expire' parameter

    4) UE <-- NW : 401 UNAUTHORIZED

    5) UE --> NW : REGISTER

      • Check Item : Check if UE contains proper authentication parameters that was requested at step 4)

    6) UE <-- NW : 200 OK

    7) UE --> NW : SUBSCRIBE

      • Check Item : Check if this message contains Event header field with 'reg'.

    8) UE <-- NW : 200 OK

    9) UE <-- NW : NOTIFY

    10) UE --> NW : 200 OK

 

 

< Detailed Test Case for Registration - Retry based on No Response>

    1) UE --> NW : REGISTER

    2) NW : Ignores the message and does not send any response

    3) UE --> NW : Resend 'REGISTER'

      • Check Point : Does UE retry ?
      • Check Point : Does UE retry with specified interval ? (This interval is specified by Service Provider. This interval can be same for every retry or varies in a certain pattern specified by Service Provider)
      • Check Point : How many times does UE retries if NW keep ignoring message ? (Number of Max retry would be specified by Service Provider)
      • Check Point : Does UE retry with the same CSCF address or different address ? (This is also specified by Service Provider)

 

 

< Detailed Test Case for Registration - Retry based on Response with Error Code>

    1) UE --> NW : REGISTER

    2) UE <-- NW : Send a Message with Error Code (Common Error Codes are 400,401,402,404,404,405,500,503)

    3) UE --> NW : Resend 'REGISTER'

      • Check Point : Does UE retry ?
      • Check Point : Does UE retry with specified interval ? (This interval is specified by Service Provider. This interval can be same for every retry or varies in a certain pattern specified by Service Provider)
      • Check Point : How many times does UE retries if NW keep ignoring message ? (Number of Max retry would be specified by Service Provider)
      • Check Point : Does UE retry with the same CSCF address or different address ? (This is also specified by Service Provider)

 

 

< Detailed Test Case for Registration - Re-Registration due to registration expiration time >

 

    1) UE --> NW : REGISTER

    2) UE <-- NW : 401 UNAUTHORIZED

    3) UE --> NW : REGISTER

    4) UE <-- NW : 200 OK with 'Expires = smaller value'.

    5) < Registration Timer gets expired >

      • Check Point : Check if UE tries Re-Registration within a certain time span.

     

 

 

< Detailed Test Case for DeRegistration - UE Initiated De-Registration >

 

    1) UE <--> NW : < Perform IMS Registration >

    2) UE : Airplane Mode or Radio Off or Power Off

    3) UE --> NW : SUBSCRIBE (This step applies only for the case where UE performed SUBSCRIBE at step 1)

      • Check Point : Check if 'Expire' value is set to be 0
      • Check Point : Event name is same as the one UE performed in Step 1)
      • Check Point : UE should not wait for 200 OK or NOTIFY and move to next step.

    4) UE --> NW : REGISTER with "Expires: 0"

    5) UE --> NW : NAS DETACH REQUEST

 

 

< Detailed Test Case for DeRegistration - Network Initiated De-Registration >

 

    1) UE <--> NW : < Perform IMS Registration >

    2) UE <-- NW : NOTIFY with any of following status and event

      • Case 1 : state = “terminated”, event = “rejected”
      • Case 2 : state = “terminated”, event = “unregistered”
      • Case 3 : state = “terminated”, event = “deactivated”

      Note 1 : Refer to 24.229 - 5.1.1.7 Network-initiated deregistration

      Note 2 : Depending on Network Operators implementation, this message would carry a huge additional information in the form of xml.

 

 

< Detailed Test Case for SCFB - VoLTE Fail and Fallback to CS >

 

    1) UE <--> NW : < Perform IMS Registration >

    2) UE : Make a VoLTE Call from UE (Make a MO Call)

    3) UE --> NW : INVITE 

    4) UE <--> INVITE session fails in many different reasons. Depending on what kind of failure it is,

                   you can create a lot of test cases. Sometimes the session fails because NW does not reply or

                   sometimes it fails because NW sends some error message etc.

    5) UE --> NW : Trigger CSFB (send 'Extended Service Request' through Radio Protocol)