IMS

 

 

 

 

Setting up a SIP test environment - 2 PCs

 

For a long time, 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

ii) 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

 

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.

 

 

 

IMS/SIP 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

    5) UE --> NW : NAS DETACH REQUEST