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 : 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.
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.
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).
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
2) UE --> NW : RRC : RRC Connection Reconfiguration Complete + NAS : Attach Complete + NAS : Activate Default EPS Bearer Context Accept 3) UE --> NW : REGISTER 4) UE <-- NW : 401 UNAUTHORIZED 5) UE --> NW : REGISTER 6) UE <-- NW : 200 OK 7) UE --> NW : SUBSCRIBE 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'
< 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'
< 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 >
< 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) 4) UE --> NW : REGISTER 5) UE --> NW : NAS DETACH REQUEST
|
||