|
IMS |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Followings are the topics to be covered in this page.
IMS (IP Multimedia Subsystem) is one of the terms that I heard most often since I started studying LTE. But this is one of the terms which is still not clear to me -:).
This post is to share my understanding as of now (?) with readers and I will try to put information based on my hands-on experience rather than directly coming from the specification. There may be some part which may not be 100% accurate from the real expert's point of view. I think I keep updating this page very often and very long.
As usual, the first thing I did to know something about IMS when I first heard of it, I put "IMS" in Google and as you may experienced I got a lot of different kind IMS -:). Then I put "LTE IMS" and got pretty much of the result being more relevent to my interest. But I saw from the searched link a lot of material about SIP. Reading through these links, I start asking myself.. "Hmm... Is IMS same as SIP ?". And then I started search "SIP" in Google. Of course, a lot of result about SIP popped up but I also got almost same amout of the searched result was about "VoIP". Then I asked myself "Hmm... Is SIP as same as VoIP ?". With the application of transition rule, I thought "Then... Is IMS same as VoIP ?". It took long time for me to get out of this confusion.
The latest version of my understanding about the relationship among IMS, SIP, VoIP is as follows ( I think there should be many other arrows in/out of IMS block). As you see, IMS is sitting on top of everything and it control/use SIP for the various media transfer. Now let's think about SIP (Session Initiation Protocol). As the name implies, SIP is a kind of signaling protocol which mainly involved in "Initiation" and "Closing" of a media transfer. Once a session is initiated, some other protocols kick in the process to transfer the data part of the media. The specific type of prtocol is determined by the type of media data.
Now let's think about how these IMS chain get involved in LTE SAE structure and I think just one diagram as shown below is good enough for a big picture. (I will put more details later).
Now let's get a little bit deeper into some of sub topics which would give you more detailed and practical information. For the start, I would describe some topics about SIP first. One reason is that SIP is one of the biggest applications of IMS framework and another reason is that I haven't yet found any small IMS test system I can try with.
First, if you are a real beginner for IMS and SIP. I recommend you to see the following video a couple of times and it will give you pretty good big pictures.
I was sitting in a couple of IMS training course. I noticed the most common questions from both instructors and audience was "How my IMS voice/data get delivered to the other side in this and that kind of situation ?". The answer never ends and question never stops.. easily eats up the most of training session. It may be an important question and answer and necessary to understand the details of IMS mechanism, but not easy to come out with "Short and Clear" answer to this kind of questions because there can be so many variation in each cases. So my intention is not to give you any single solid answer for "IMS Data Path", but to give you some guide line (or logics of thinking) on IMS data delivery.
First, I want you to get yourself familiar with the following diagram.
There are several common rules which can help you to get the answer for data path by yourself.
With these rules in mind (I am pretty sure that I would have missed rules), please print out the diagram above and set a specific scenario (e.g, 'I want to make a call from UA1 to UA2' or from UA1 to UA3 etc) and draw the lines for data path. Don't worry about getting wrong.. you may be wrong in a couple of points but at least more than 70% you would be right if you apply the rule listed above.
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.
< REGISTRATION with Authentication>
Following is an example for this process.
Step 1 : REGISTER -------------------------------- REGISTER sip:test.3gpp.com SIP/2.0 f: <sip:+11234567890@test.3gpp.com>;tag=2722997041 t: <sip:+11234567890@test.3gpp.com> CSeq: 575513373 REGISTER i: 2722997021_2363003016@2001::21f:29ff:fe7c:8f51 v: SIP/2.0/UDP [2001::21f:29ff:fe7c:8f51]:5060;branch=z9hG4bK656994275 Max-Forwards: 70 m: <sip:+11234567890@[2001::21f:29ff:fe7c:8f51]:5060> P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=3114800102FFFFFFF l: 0 Authorization: Digest uri="sip:test.3gpp.com", username="001010123456789@test.3gpp.com", response="", realm="test.3gpp.com", nonce="" Expires: 7200
Note 1 : Make it sure the 'realm' parameter matches Authentication server domain name. If this does not matches the authentication server, CSCF may send 'Error Code'.
Step 2 : 401 UNAUTHORIZED -------------------------------- SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP [2001::21f:29ff:fe7c:8f51]:5060;branch=z9hG4bK656994275 From: <sip:+11234567890@test.3gpp.com>;tag=2722997041 To: <sip:+11234567890@test.3gpp.com>;tag=T3E04A4B5 Call-ID: 2722997021_2363003016@2001::21f:29ff:fe7c:8f51 CSeq: 575513373 REGISTER Content-Length: 0 WWW-Authenticate: Digest realm="test.3gpp.com", nonce="qlWqVapVqlWqVapVqlWqVUUQA5HEt9VVZ3t1TM221cg=", qop="auth", opaque="MTcyMjU3ODA2NDo=SU1TLVNJUCBTZXJ2ZXI=", algorithm=AKAv1-MD5 P-Associated-URI: <sip:+11234567890@TEST.3GPP.COM> P-Associated-URI: <tel:+11234567890>
Note 1 : 'realm' parameter in this message should match the 'realm' parameter in Step 1. Otherwise, UE may not proceed to next step. Note 2 : 'algorithm' specified here should be the one supported by UE. Otherwise, UE may not proceed to next step.
Step 3 : REGISTER ----------------------------------- REGISTER sip:test.3gpp.com SIP/2.0 f: <sip:+11234567890@test.3gpp.com>;tag=2722997284 t: <sip:+11234567890@test.3gpp.com> CSeq: 575513374 REGISTER i: 2722997021_2363003016@2001::21f:29ff:fe7c:8f51 v: SIP/2.0/UDP [2001::21f:29ff:fe7c:8f51]:5060;branch=z9hG4bK843051065 Max-Forwards: 70 m: <sip:+11234567890@[2001::21f:29ff:fe7c:8f51]:5060> P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=3114800102FFFFFFF l: 0 Authorization: Digest username="001010123456789@test.3gpp.com", realm="test.3gpp.com", uri="sip:test.3gpp.com", qop=auth, nonce="qlWqVapVqlWqVapVqlWqVUUQA5HEt9VVZ3t1TM221cg=", nc=00000001, cnonce="11259375", algorithm=AKAv1-MD5, response="a3f549b13f477562f4445b7277cd83c1", opaque="MTcyMjU3ODA2NDo=SU1TLVNJUCBTZXJ2ZXI=" Expires: 7200
Note 1 : 'realm' parameter in this message should match the 'realm' parameter in Step 2. Note 2 : 'algorithm' parameter in this message should match the 'algorithm' parameter in Step 2. Note 3 : 'Expires : 7200' means that the registration should be 'renewed' within 7200 seconds.
Step 4 : 200 OK ----------------------------------- SIP/2.0 200 OK Via: SIP/2.0/UDP [2001::21f:29ff:fe7c:8f51]:5060;branch=z9hG4bK843051065 From: <sip:+11234567890@test.3gpp.com>;tag=2722997284 To: <sip:+11234567890@test.3gpp.com>;tag=T44F6AE74 Call-ID: 2722997021_2363003016@2001::21f:29ff:fe7c:8f51 CSeq: 575513374 REGISTER Contact: <sip:+11234567890@[2001::21f:29ff:fe7c:8f51]:5060>;q=0.500;expires = 7200 Content-Length: 0 Date: Mon, 22 Apr 2013 15:43:15 GMT Authentication-Info: qop=auth, rspauth="a3f549b13f477562f4445b7277cd83c1", cnonce="11259375", nc=00000001 P-Associated-URI: <sip:+11234567890@TEST.3GPP.COM> P-Associated-URI: <tel:+11234567890> P-Associated-URI: <sip:+11234567890@TEST.3GPP.COM> P-Associated-URI: <tel:+11234567890>
SUSCRIBE message is similar to "Measurement Control" or "Information Request" on Radio Protocol. It request the other party to report on any specific event or specific status. NOTIFY is similar to "Measurement Report" or "Information Response" on Radio Protocol. Basically it delivers the information that is requested by SUBSCRIBE message. Overall sequence for SUBSCRIBE and NOTIFY goes as follows.
Step 1 : SUBSCRIBE ----------------------------------- SUBSCRIBE sip:+11234567890@test.3gpp.com SIP/2.0 Via: SIP/2.0/UDP 10.133.202.46:50997;branch=z9hG4bK2968d27245f17c7bcae38c31991bfdaa Max-Forwards: 70 Contact: <sip:+11234567890@10.133.202.46:50997>;+sip.instance="<urn:gsma:imei:00440113-904785-0>" To: <sip:+11234567890@test.3gpp.com> From: <sip:+11234567890@test.3gpp.com>;tag=210a54 Call-ID: d57a0b04-785ba328-13a4d876@10.133.202.46 CSeq: 14534 SUBSCRIBE Expires: 600000 User-Agent: IM-client/OMA1.0 DUT-IMS Event: reg Accept: application/reginfo+xml P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp="0010100010000000" P-Preferred-Identity: <sip:+11234567890@test.3gpp.com> Content-Length: 0
Step 2 : 200 OK ----------------------------------- SIP/2.0 200 OK Via: SIP/2.0/UDP 10.133.202.46:50997;branch=z9hG4bK2968d27245f17c7bcae38c31991bfdaa From: <sip:+11234567890@test.3gpp.com>;tag=210a54 To: <sip:+11234567890@test.3gpp.com>;tag=987654321 Call-ID: d57a0b04-785ba328-13a4d876@10.133.202.46 CSeq: 14534 SUBSCRIBE Expires: 600000 Contact: <sip:10.133.202.47:5060> Record-Route: <sip:10.133.202.47;lr> Content-Length: 0
Step 3 : NOTIFY ----------------------------------- NOTIFY sip:+11234567890@test.3gpp.com SIP/2.0 Via: SIP/2.0/UDP 10.133.202.47:5060;branch=z9hG4bK-d1e4c4961ca9d523ae76b67e088589cd Call-ID: d57a0b04-785ba328-13a4d876@10.133.202.46 From: <sip:+11234567890@test.3gpp.com>;tag=987654321 To: <sip:+11234567890@test.3gpp.com>;tag=210a54 Subscription-State: active;expires=600000 Event: reg CSeq: 14534 NOTIFY Contact: <sip:10.133.202.47:5060> Max-Forwards: 70 Content-Type: application/reginfo+xml Content-Length: 340
<?xml version="1.0" encoding="UTF-8"?> <reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="0" state="full"> <registration aor="sip:+11234567890@test.3gpp.com" id="12345" state="active"> <contact id="100" state="active" event="registered" expires="600000"> <uri>sip:+11234567890@10.133.202.46:50997</uri> </contact> </registration> </reginfo>
Step 4 : 200 OK ----------------------------------- SIP/2.0 200 OK Via: SIP/2.0/UDP 10.133.202.47:5060;branch=z9hG4bK-d1e4c4961ca9d523ae76b67e088589cd Max-Forwards: 70 Contact: <sip:+11234567890@10.133.202.46:50997>;+sip.instance="<urn:gsma:imei:00440113-904785-0>" To: <sip:+11234567890@test.3gpp.com>;tag=210a54 From: <sip:+11234567890@test.3gpp.com>;tag=987654321 Call-ID: d57a0b04-785ba328-13a4d876@10.133.202.46 CSeq: 14534 NOTIFY Allow: NOTIFY,SUBSCRIBE Content-Length: 0
Most of basic SIP protocol goes as the combination of the procedures explained above. This shows an example showing the interplay of these procedures.
If you see the following sample sequence, you will find various example ranging from very simple and pretty much complicated ones.
Following Wireshark capture is the one that I captured using the test configuration described in previous section.
Following is the filtered log showing only signaling part of VoIP calls that I did.
Following is the one showing both signaling part and data traffic parts showing various protocols being used in media transfer.
Following illustration is based on the IMS registration sequence posted on EventHelix. I converted the sequence diagram into IMS architecture diagram so that you can get some better idea of interplay of each components. Try to follow the big picture and understand overall logic. The very detailed sequence and parameters may vary depending on the network organization. So the log you collected from a specific network may be different from what you see here. If you have a log from a test equipment, it may be simpler than what you see here.
In Full IMS registration, it can be split into three major process as shown below.
< Unauthenticated IMS Registration Attempt >
Following is the first main procedure - Unauthenticated IMS Registration Attempt.
(1) : REGISTER (Path : UA1 --> eNodeB --> S-GW --> P-GW --> P-CSCF)
REGISTER sip:hims.net SIP/2.0, Via: SIP/2.0/UDP UE-IP;branch=0abab, Route: sip:[P-CSCF-IP], // Route specifies the IP of next node for this REGISTER to reach. In this case, 'Next Node' is P-CSCF Max-Forwards: 20, From: <sip:name@hims.net>;tag=abbb, To: <sip:name@hims.net>, Contact: <sip:[UE-IP]>;expires=90000, Call-ID: ababab, CSeq: 25 REGISTER, Security-Client: port-s, port-c, Authorization: Digest username = name.private@hims.net, Content-Length: 0
Note : Since this step is 'REGISTER' process, 'Authentication' parameter does not carry any specific information for Authentication algorithm. Following is one example that I captured from test equipment. Authorization: Digest uri="sip:test.3gpp.com", username="001010123456789@test.3gpp.com", response="", realm="test.3gpp.com", nonce=""
(2): DNS Query (Path : P-CSCF --> DNS Server) DNS Query for I-CSCF IP
(3): DNS Response (Path : DNS Server --> P-CSCF) DNS Response for I-CSCF IP
(4) : REGISTER (Path : P-CSCF --> I-CSCF)
REGISTER sip:hims.net SIP/2.0, Via: SIP/2.0/UDP pcscf1.vims.net;branch=0aab1, Via: SIP/2.0/UDP UE-IP;branch=0abab, Max-Forwards: 19, From: <sip:name@hims.net>;tag=abbb, To: <sip:name@hims.net>, Contact: <sip:[UE-IP]>;expires=90000, Call-ID: ababab, CSeq: 25 REGISTER, Content-Length: 0, Authorization: Digest username = name.private@hims.net integrity protection:no
(5) : User Authorization Request (Path : I-CSCF --> HSS)
(6) : User Authorization Answer (Path : HSS --> I-CSCF)
S-CSCF Name, S-CSCF Capabilities
(7) : REGISTER (Path : I-CSCF --> S-CSCF)
REGISTER sip:hims.net SIP/2.0, Via: SIP/2.0/UDP icscf1.hims.net;branch=0aab2, Via: SIP/2.0/UDP pcscf1.vims.net;branch=0aab1, Via: SIP/2.0/UDP UE-IP;branch=0abab, Route: sip:scscf1.hims.net,Max-Forwards: 18, From: <sip:name@hims.net>;tag=abbb, To: <sip:name@hims.net>, Contact: <sip:[UE-IP]>;expires=90000, Call-ID: ababab, CSeq: 25 REGISTER, Content-Length: 0, Authorization: Digest username =name.private@hims.net integrity protection:no
(8) : Multimedia Authentication Request (Path : S-CSCF --> HSS)
(9) : Multimedia Authentication Response (Path : HSS --> S-CSCF) S-CSCF does followings at this point
(10) : 401 UnAuthorized (Path : S-CSCF --> I-CSCF)
WWW-Authenticate: nonce=RAND-AUTN, ck, ik, Via: icscf1, pcscf1, ue-ip
Note : This message will tell UE to initiate 'REGISTER' with authentication based on the information under 'WWW-Authenticate'. An example is as follows. WWW-Authenticate: Digest realm="test.3gpp.com", nonce="qlWqVapVqlWqVapVqlWqVUUQA5HEt9VVZ3t1TM221cg=", qop="auth", opaque="MTcyMjU3ODA2NDo=SU1TLVNJUCBTZXJ2ZXI=", algorithm=AKAv1-MD5
(11) : 401 UnAuthorized (Path : I-CSCF --> P-CSCF)
WWW-Authenticate: nonce=RAND-AUTN, ck, ik, Via: pcscf1, ue-ip
P-CSCF does followings at this point
(12) : 401 UnAuthorized (Path : P-CSCF --> P-GW --> S-GW --> eNodeB --> UA1)
WWW-Authenticate: nonce=RAND-AUTN, Security-Server: port-s, port-c
< IPSec Security Association Establishment >
(1) : IPSec SA for UE Initiated Requests UE-Client -> P-CSCF-Server
(2) : IPSec SA for Responses to UE UE-Server <- P-CSCF-Client
(3) : IPSec SA for P-CSCF Initiated Requests UE-Server <- P-CSCF-Client
(4) : IPSec SA for Responses to P-CSCF UE-Client -> P-CSCF-Server
< Authenticated IMS Registration >
(1) REGISTER (Path : UA1 --> eNodeB --> S-GW --> P-GW --> P-CSCF) Via: UE-IP;UE-Server-Port, Route: pcscf1, pcscf-server-port, Contact: UE-IP ue-server-port, Authorization: Digest username = name.private@hims.net response=RES Note : Since this step is for Registration with Authentication, 'Authentication' parameter carries detailed information needed for the authentication algorith as shown below. This step is triggered by '401 UnAuthorized' in previous registration step. Authorization: Digest username="001010123456789@test.3gpp.com", realm="test.3gpp.com", uri="sip:test.3gpp.com", qop=auth, nonce="qlWqVapVqlWqVapVqlWqVUUQA5HEt9VVZ3t1TM221cg=", nc=00000001, cnonce="11259375", algorithm=AKAv1-MD5, response="a3f549b13f477562f4445b7277cd83c1", opaque="MTcyMjU3ODA2NDo=SU1TLVNJUCBTZXJ2ZXI="
(2) REGISTER (Path : P-CSCF --> I-CSCF) Via: pcscf1 UE-IP;UE-Server-Port, Contact: UE-IP ue-server-port, Authorization: Digest username = name.private@hims.net response=RES integrity protection: yes,RES
(3) User Authorization Request (Path : I-CSCF --> HSS) name.private@hims.net
(4) User Authorization Response (Path : HSS --> I-CSCF) S-CSCF Name, S-CSCF Capabilities
(5) REGISTER (Path : I-CSCF --> S-CSCF) Via: icscf1 pcscf1 UE-IP;UE-Server-Port, Contact: UE-IP ue-server-port, Authorization: Digest username =name.private@hims.net response=RES integrityprotection: yes,RES
(6) Server Assignment Request (Path : S-CSCF --> HSS) name.private@hims.net
(7) Server Assignment Request (Path : HSS --> S-CSCF)
(8) 200 OK (Path : S-CSCF --> I-CSCF)
(9) 200 OK (Path : I-CSCF --> P-CSCF)
(10) 200 OK (Path : P-CSCF --> P-GW --> S-GW --> eNodeB --> UA1)
There is no specific message for UnRegistration. SIP uses 'REGISTER' message for Unregistration as well. Just setting 'Expires' field to be 0 perform SIP Unregistration.
REGISTER sip:test.3gpp.com SIP/2.0 f: <sip:+11234567890@test.3gpp.com>;tag=589636628 t: <sip:+11234567890@test.3gpp.com> CSeq: 589636509 REGISTER i: 589636508_2363003488@10.133.202.46 v: SIP/2.0/UDP 10.133.202.46:5060;branch=z9hG4bK428556305 Max-Forwards: 70 m: <sip:+11234567890@10.133.202.46:5060> P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=3114800001FFFFFFF Expires: 0 l: 0 Authorization: Digest uri="sip:test.3gpp.com",username="001010123456789@test.3gpp.com",response="",realm="test.3gpp.com",nonce="",Digest uri="sip:test.3gpp.com",username="001010123456789@test.3gpp.com",response="",realm="test.3gpp.com",nonce=""
What is "fork" ? Yes.. it is what you think of now. It is one of the most common tools you use when you eat something. If you look at the shape, a handle (grabbing part) is splitted into multiple thin branches. If you are familiar with Unix/Linux programming, you will be well aware of 'fork'. Basically it is a method of creating multiple child process from a process.
SIP Forking means similar thing. You can think of this as a mechanism to split a SIP call into multiple clones for multiple endpoints.
I found a very good high level description of SIP forking from 3CX website (http://www.3cx.com/faqs/copyofauto-attendant/) as below.
SIP forking refers to the process of “forking” a single SIP call to multiple SIP endpoints. This is a very powerful feature of SIP. A single call can ring many endpoints at the same time. With SIP forking you can have your desk phone ring at the same time as your softphone or a SIP phone on your mobile. For example, you would use SIP forking to ring your deskphone and your Android SIP Phone at the same time, allowing you to take the call from either device easily. No forwarding rules would be necessary as both devices would ring. In the same manner SIP forking can be used in an office and allow the secretary to answer calls to the extension of his/her boss when he is away or unable to take the call.
Overall flow goes like this : i) a UA send INVITE and this message reaches Proxy Server ii) the Proxy server has information on which multiple endpoints it has to deliver (fork) the messages and fork the INVITE to each of endpoints
There are mainly two different types of forking. Parallel and Sequencial Forking. In Parallel forking, the call gets splitted and conveyed to multiple endpoints simultaneously. In Sequencial forking, the call gets delivered to an end point and gets forked only when there is no response from the first end point.
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.
As XML gets more widely used, now it gets used as a standard form of storing various configurations in mobile devices and exchanging short informations like supplimentary services.
XDM (XML Document Management) and XCAP (XML Configuration Access Protocol) is designed to provide standard way of managing and exchanging information in the form of XML (3GPP 24.623 for the details).
XCAP protocol allows a client to read, write, and modify application configuration data stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. An XCAP server is used by the XCAP clients to store data like Presence policy in combination with a SIP server that supports PUBLISH/SUBSCRIBE/NOTIFY methods to provide a complete SIP SIMPLE server solution.
You can find good introductions from followings
As more and more people gets interested in IMS more than the simple SMS, I am hearing more and more about RCS. RCS stands for 'Rich Communication Service'. You will find quite a lot of material by googling it, but it would be hard to get a 'short/tangible' understanding of what it really is. Is RCS a kind of specification ? Is it a kind of software package ? Is it a kind of name for a technology ?
Confused !!!...
Whenevery you get confused by anything when you try to catching up the new technology/words, one of the best way would be to refer to any person/document from which/who the word/technology is orignated.
It seems that the origination of RCS/RCS-e comes from GSMA. So I decided to dig things from GSMA.
A simple/clear definition of RCS/RCS-e from http://www.gsma.com/rcs-faqs/
Another good definition of RCS can be found at Wikipedia (http://en.wikipedia.org/wiki/Rich_Communication_Suite) as follows.
If you want some intuitive 'feeling' about this, go to http://www.youtube.com/user/RCSChannel
As is described above, RCS initiative is a "joint efffort in the industry". It implies that many stakeholders in the industry (both Network Operators and UE manufacturer) should join in the effort and come out with some 'agreed rule (specification)' and implement them according to the specification. I don't know exactly how many Network Operators and UE makers are participating in this joint effort, but seems that there would be over 80 companies (Network Operators + UE Maker).
There are very wide spectrum of technicalogies specified in the RCS, but a couple of Core technology that almost everybody talks about RCS are as follows.
i) Enhanced Phonebook : This phone book give you not only simple phone numbers but also presence information and service capability. With these information, you can initiate the communication by selecting one of the available communication types. You can use the Presence information to communicate any personalized contact features including photo, availability and free text ii) Enhanced Messaging : This enables a large variety of messaging options like SMS, MMS, Instant Messaging and buddy related communication history. iii) Enriched Call : This enables multimedia contents sharing during the voice call. (e.g, video share, image share and file transfer)
You can find the detailed Technical Specification of RCS-e from If you are interested specifically on how to test these features, please refer to the test specification at GSMA site. RCE IOT001 RCS-e Test Cases.
SIP Message Structure - Examples
Note : This examples is showing one of my log being interpreted according to the example from E-multimedia : http://www.siptutorial.net/SIP/request.html. For the part which is not described in this tutorial, I refered to RFC 3261.
[ Line 1 ] REGISTER sip:ims.sharetechnote.com SIP/2.0 [ Line 2 ] Via: SIP/2.0/UDP 192.168.1.15:5060;branch=z9hG4bK3933794001smg;transport=UDP [ Line 3 ] Expires: 3600 [ Line 4 ] Route: <sip:192.168.1.2:5060;lr> [ Line 5 ] P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=0000054200000000 [ Line 6 ] User-Agent: SP VOIP IMS 2.0 [ Line 7 ] Privacy: none [ Line 8 ] Contact: <sip:+11234567890@192.168.1.15:5060> [ Line 9 ] Authorization: Digest username="001010123456789@ims.sharetechnote.com", realm="ims.sharetechnote.com", uri="sip:ims.sharetechnote.com", nonce="", response="" [ Line 10 ] From: <sip:+11234567890@ims.sharetechnote.com>;tag=2504745718 [ Line 11 ] To: <sip:+11234567890@ims.sharetechnote.com> [ Line 12 ] Call-ID: 500949143@192.168.1.15 [ Line 13 ] CSeq: 1 REGISTER [ Line 14 ] Max-Forwards: 70 [ Line 15 ] Content-Length: 0
[ Line 1 ] The first line of the text-encoded message is called Request-Line. It identifies that the message is a request. It has format : Method SP Request-URI SP SIP-Version CRLF Method : REGISTER SP : Single Space Request-URI : sip:test.3pgg.com SP : Single Space SIP-Version : SIP/2.0
[ Line 2 ] Via: This represents the local address of the first node (192.168.1.15:5060 in this case which is same as the caller) where it is expecting the responses to come
[ Line 3 ] Expires : The Expires header field gives the relative time after which the message (or content) expires. The unit is sec. (See "20.19 Expires" of RFC 3261). In case of this example, it means "REGISTER" would expire in 3600 seconds. It means if UE does not renew the registration, the registration status will be cancelled.
[ Line 4 ] Route: This field is used to force routing for a request through the listed set of proxies. This means that the 'REGISTER' message should go through the proxy 192.168.1.2:5060. (See "20.34 Route" of RFC 3261)
[ Line 8 ] Contact: This carries a SIP or SIPS URI that is a direct route to the originator. It contains a username and a fully qualified domain name(FQDN). It may also have an IP address. Via field is used to send the response to the request. Contact field is used to send future requests. That is why the 200 OK response from the recipient goes to the caller through proxies. But when the recipient generates after the 200 OK, it goes directly to the originator bypassing the proxies
[ Line 9 ] Authorization: The Authorization header field contains authentication credentials of a UA. (Refer to "22.2 User-to-User Authentication" of RFC 3261)
[ Line 10 ] From: This carries a display name and a SIP or SIPS URI "11234567890@ims.sharetechnote.com". It also contains a tag which is a pseudo-random sequence inserted by the SIP application. It works as an identifier of the caller in the dialog.
[ Line 12 ] Call-ID: It is a globally unique identifier of the call generated as the combination of a pseudo-random string and the softphone's IP address.The Call-ID is unique for a call. A call may contain several dialogs. Each dialog is uniquely identified by a combination of From, To and Call-ID.
[ Line 13 ] CSeq: This shows an integer and a method name. When a transaction starts, the first message is given a random CSeq. After that it is incremented by one with each new message. It is used to detect non-delivery of a message or out-of-order delivery of messages
[Line 14 ] Max-Forwards : This is used to limit the number of hops that this request may take before reaching the callee It is decreased by one at each hop. It is necessary to prevent the request from traveling forever in case it is trapped in a loop.
< Example : 200 OK to REGISTER >
: Most of the part is same as the example above. So I would explain things that has not covered above.
[ Line 1 ] SIP/2.0 200 OK [ Line 2 ] Via: SIP/2.0/UDP 192.168.1.15:5060;branch=z9hG4bK3933794001smg;transport=UDP [ Line 3 ] From: <sip:+11234567890@ims.sharetechnote.com>;tag=2504745718 [ Line 4 ] To: <sip:+11234567890@ims.sharetechnote.com>;tag=987654321 [ Line 5 ] Call-ID: 500949143@192.168.1.15 [ Line 6 ] CSeq: 1 REGISTER [ Line 7 ] Allow: INVITE, ACK, CANCEL, BYE, PRACK, MESSAGE [ Line 8 ] Supported: 100rel, timer [ Line 9 ] Date: Tue, 27 Mar 2012 19:49:16 GMT [ Line 10 ] Contact: <sip:+11234567890@192.168.1.15:5060>;expires=3600 [ Line 11 ] Content-Length: 0
[ Line 7 ] Allow: This Field lists the set of methods supported by the UA which generate the message. (See "20.5 Allow" of RFC 3261).
[ Line 8 ] Supported: This field enumerates all the extensions supported by the UAC(User Agent Client) or UAS(User Agent Server). (See "20.37 Supported" of RFC 3261).
[ Line 1 ] SUBSCRIBE sip:+11234567890@test.3gpp.com SIP/2.0 [ Line 2 ] Via: SIP/2.0/UDP 10.133.202.46:50997;branch=z9hG4bK2968d27245f17c7bcae38c31991bfdaa [ Line 3 ] Max-Forwards: 70 [ Line 4 ] Contact: <sip:+11234567890@10.133.202.46:50997>;+sip.instance="<urn:gsma:imei:00440113-904785-0>" [ Line 5 ] To: <sip:+11234567890@test.3gpp.com> [ Line 6 ] From: <sip:+11234567890@test.3gpp.com>;tag=210a54 [ Line 7 ] Call-ID: d57a0b04-785ba328-13a4d876@10.133.202.46 [ Line 8 ] CSeq: 14534 SUBSCRIBE [ Line 9 ] Expires: 600000 [ Line 11] User-Agent: IM-client/OMA1.0 DUT-IMS [ Line 12] Event: reg [ Line 13] Accept: application/reginfo+xml [ Line 14] P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp="0010100010000000" [ Line 15] P-Preferred-Identity: <sip:+11234567890@test.3gpp.com> [ Line 16] Content-Length: 0
: Most of the part is same as the examples above. So I would explain things that has not covered above. (Refer to 7.1.2. NOTIFY of RFC 3265 for the details)
[ Line 1 ] NOTIFY sip:+11234567890@ims.sharetechnote.com SIP/2.0 [ Line 2 ] Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bK-fa1fec3c8c092d3c03c8555617fa1730;transport=UDP [ Line 3 ] Call-ID: 2489100824@192.168.1.15 [ Line 4 ] From: <sip:+11234567890@ims.sharetechnote.com>;tag=987654321 [ Line 5 ] To: <sip:+11234567890@ims.sharetechnote.com>;tag=3855569531 [ Line 6 ] Subscription-State: active;expires=3600 [ Line 7 ] Event: reg [ Line 8 ] CSeq: 1 NOTIFY [ Line 9 ] Contact: <sip:192.168.1.2:5060> [ Line 10 ] Max-Forwards: 70 [ Line 11 ] Content-Type: application/reginfo+xml [ Line 12 ] Content-Length: 336 [ Line 13 ] <reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="0" state="full"> <registration aor="sip:+11234567890@ims.sharetechnote.com" id="12345" state="active"> <contact id="100" state="active" event="registered" expires="3600"> <uri>sip:+11234567890@192.168.1.15:5060</uri> </contact></registration></reginfo>
[ Line 1 ] INVITE sip:+10123456789@ims.sharetechnote.com SIP/2.0 [ Line 2 ] Via: SIP/2.0/UDP 192.168.1.15:5060;branch=z9hG4bK3298736468smg;transport=UDP [ Line 3 ] Supported: 100rel,timer [ Line 4 ] Allow: INVITE, ACK, CANCEL, UPDATE, BYE [ Line 5 ] P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=0000054200000000 [ Line 6 ] P-com.HDVVServiceType: MYIMSv1 [ Line 7 ] User-Agent: SP VOIP IMS 2.0 [ Line 8 ] Session-Expires: 1800;refresher=uac [ Line 9 ] Content-Type: application/sdp [ Line 10 ] Route: <sip:192.168.1.2:5060;lr> [ Line 11 ] Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel" [ Line 12 ] From: <sip:+11234567890@ims.sharetechnote.com>;tag=659747293 [ Line 13 ] To: <sip:+10123456789@ims.sharetechnote.com> [ Line 14 ] Call-ID: 131949458@192.168.1.15 [ Line 15 ] CSeq: 1 INVITE [ Line 16 ] Max-Forwards: 70 [ Line 17 ] Contact: <sip:+11234567890@192.168.1.15:5060;transport=UDP>; +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel" [ Line 18 ] Content-Length: 387
[ Line 19 ] v=0 [ Line 20 ] o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 [ Line 21 ] s=SDP Seminar [ Line 22 ] i=A Seminar on the session description protocol [ Line 23 ] u=http://www.cs.ucl.com/Rob/sdp.03.ps [ Line 24 ] e=mjh@isi.edu (Rob) [ Line 25 ] c=IN IP4 224.2.17.12/127 [ Line 26 ] t=2873397496 2873404696 [ Line 27 ] a=recvonly [ Line 28 ] m=audio 49170 RTP/AVP 0 [ Line 29 ] m=video 51372 RTP/AVP 31 [ Line 30 ] m=application 32416 udp wb [ Line 31 ] a=orient:portrait
Note : Line 19-31 is from the example in RFC 2327
[ Line 1 ] SIP/2.0 100 Trying [ Line 2 ] Via: SIP/2.0/UDP 192.168.1.15:5060;branch=z9hG4bK3298736468smg;transport=UDP [ Line 3 ] To: <sip:+10123456789@ims.sharetechnote.com> [ Line 4 ] From: <sip:+11234567890@ims.sharetechnote.com>;tag=659747293 [ Line 5 ] Call-ID: 131949458@192.168.1.15 [ Line 6 ] CSeq: 1 INVITE [ Line 7 ] Content-Length: 0
[ Line 1 ] SIP/2.0 180 Ringing [ Line 2 ] Via: SIP/2.0/UDP 192.168.1.15:5060;branch=z9hG4bK3298736468smg;transport=UDP [ Line 3 ] To: <sip:+10123456789@ims.sharetechnote.com>;tag=123456789 [ Line 4 ] From: <sip:+11234567890@ims.sharetechnote.com>;tag=659747293 [ Line 5 ] Max-Forwards: 70 [ Line 6 ] Contact: <sip:+10123456789@192.168.1.2:5060;transport=udp> [ Line 7 ] Call-ID: 131949458@192.168.1.15 [ Line 8 ] Record-Route: <sip:192.168.1.2:5060;lr> [ Line 9 ] CSeq: 1 INVITE [ Line 10 ] Content-Length: 0
[ Line 1 ] SIP/2.0 200 OK [ Line 2 ] Via: SIP/2.0/UDP 192.168.1.15:5060;branch=z9hG4bK3298736468smg;transport=UDP [ Line 3 ] To: <sip:+10123456789@ims.sharetechnote.com>;tag=123456789 [ Line 4 ] From: <sip:+11234567890@ims.sharetechnote.com>;tag=659747293 [ Line 5 ] Max-Forwards: 70 [ Line 6 ] Contact: <sip:+10123456789@192.168.1.2:5060;transport=udp> [ Line 7 ] Call-ID: 131949458@192.168.1.15 [ Line 8 ] Record-Route: <sip:192.168.1.2:5060;lr> [ Line 9 ] CSeq: 1 INVITE [ Line 10 ] Content-Type: application/sdp [ Line 11 ] Supported: timer [ Line 12 ] Allow: INVITE, ACK, CANCEL, BYE, PRACK, MESSAGE [ Line 13 ] Content-Length: 379
[ Line 14 ] v=0 [ Line 15 ] o=MYIMS 1 1 IN IP4 192.168.1.2 [ Line 16 ] s=- [ Line 17 ] i=A VOIP Session [ Line 18 ] c=IN IP4 192.168.1.2 [ Line 19 ] t=0 0 [ Line 20 ] m=audio 53746 RTP/AVP 107 97 110 [ Line 21 ] b=AS:49 [ Line 22 ] b=RS:800 [ Line 23 ] b=RR:2400 [ Line 24 ] a=ptime:20 [ Line 25 ] a=maxptime:20 [ Line 26 ] a=rtpmap:107 AMR-WB/16000 [ Line 27 ] a=fmtp:107 octet-align=1; mode-set=2 [ Line 28 ] a=rtpmap:97 AMR/8000 [ Line 29 ] a=fmtp:97 octet-align=1; mode-set=7 [ Line 30 ] a=rtpmap:110 telephone-event/8000 [ Line 31 ] a=fmtp:110 0-15 [ Line 32 ] a=mid:0 [ Line 33 ] a=sendrecv
[ Line 1 ] ACK sip:+10123456789@192.168.1.2:5060;transport=udp SIP/2.0 [ Line 2 ] Via: SIP/2.0/UDP 192.168.1.15:5060;branch=z9hG4bK3608780455smg;transport=UDP [ Line 3 ] From: <sip:+11234567890@ims.sharetechnote.com>;tag=659747293 [ Line 4 ] To: <sip:+10123456789@ims.sharetechnote.com>;tag=123456789 [ Line 5 ] CSeq: 1 ACK [ Line 6 ] Call-ID: 131949458@192.168.1.15 [ Line 7 ] Max-Forwards: 70 [ Line 8 ] Route: <sip:192.168.1.2:5060;lr> [ Line 9 ] Contact: <sip:+11234567890@192.168.1.15:5060;transport=UDP>; +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel" [ Line 10 ] Content-Length: 0
[ Line 1 ] BYE sip:+10123456789@192.168.1.2:5060;transport=udp SIP/2.0 [ Line 2 ] Via: SIP/2.0/UDP 192.168.1.15:5060;branch=z9hG4bK864033094smg;transport=UDP [ Line 3 ] From: <sip:+11234567890@ims.sharetechnote.com>;tag=659747293 [ Line 4 ] To: <sip:+10123456789@ims.sharetechnote.com>;tag=123456789 [ Line 5 ] CSeq: 2 BYE [ Line 6 ] Call-ID: 131949458@192.168.1.15 [ Line 7 ] Max-Forwards: 70 [ Line 8 ] Route: <sip:192.168.1.2:5060;lr> [ Line 9 ] Contact: <sip:+11234567890@192.168.1.15:5060;transport=UDP>; +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel" [ Line 10 ] Content-Length: 0
This is based on RFC 3261
1. Request Message
2. Response Message
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
