Ensuring Quality in IMS

IMS Interface Reference

In doing some final checks on the forthcoming IMS Poster follow-up to the book, I noticed there were several inconsistencies between our label interfaces in the Chapter 3 graphics and tables.

Rather than read thought the dozens of pages of 3GPP specs to check I did a quick check on a few of them and came across the latest Wikipedia entry for IMS here: http://en.wikipedia.org/wiki/IP_Multimedia_Subsystem

This is a great entry that I would recommend for use as a reference. It does not contain references to all of the R7 architecture (i.e. A-BGF is missing), but it looks like it covers R6 fairly well. In addition, all of the hotlinks make navaging the 3GPP specs a lot easier.

Look for some book corrections soon.

What is ESTI?

Thanks to Tom at Vonage's eagle eye on finding another another typo. On Page 2 in Section 1.1.2 Standards Ambiguity we wrote ESTI TISPAN instead of ETSI TISPAN. Looks like this is the only place we made this error - unfortunately it was in the very beginning.

What Happened to IMS?

Here are some notes I put together for a presentation that covered the current state of the IMS market.

IMS as part of the Hype Cycle

There has been a lot of speculation about the future of IMS, leading some to think IMS will never really take off. We think IMS is following a typical technology “hype cycle”. Gartner describes a typical hype cycle as starting with a technology trigger that leads to inflated expectations followed by a “trough of disillusionment” as the industry tries to commercialize. Eventually they figure it out leading to a “slope of enlightenment”.

The IMS buzz started in 2005 and really hit its peak in 2006 when everyone was talking about IMS. Well it seemed in 2007 that few people were buying IMS. As we’ll show in the next slide, this is changing as the industry starts to figure out how to make money with IMS.

IMS in 2008:

1. IMS standards are maturing alleviating standards ambiguity problems and making them more robust and practical to use. 3GPP R7 has been frozen and R8 is in progress.
2. Nearly every NEM has fully embraced IMS – you’ll notice most of them describing their products in terms of IMS, and some, like Sonus and Alcatel-Lucent are describing their products almost exclusively in IMS terms.
3. The industry is proving IMS works. In a few weeks we will participate in our 4th IMS Forum industry Plugfest, demonstrating multi-vendor IMS interoperability and new services on an IMS architecture. We will also participate in MSF GMI 2008 – another major industry event demonstrating multi-network interoperability among dozens of major vendors and several Tier 1 Service providers, including Verizon and BT.
4. Service Providers are buying IMS – in addition to the dozens of smaller-scale deployments (some vendors would claim upwards of a  100), several Tier 1 service providers will complete their evaluations and announcement major IMS contracts.

A-IMS Dead? The end of standard's ambiguity?

I recently found out that Verizon Wireless's A-IMS initiative was called off internally last November.

A-IMS was started a few years ago by Verizon Wireless to provide several practical enhancements to IMS architecture. The effort was backed by several of VZW's IMS vendors and some of these recommendations are being incorporated by the 3GPP spec.

From a quality perspective, one less standard (or quasi-standard) to test for and interoperate with is a good thing. ETSI's move to allow the 3GPP to handle the core IMS specifications last summer(http://www.etsi.org/WebSite/NewsandEvents/2007_06_common_ims.aspx) was also a big step in this direction. With PacketCable requirements being built in to R8, we may be only a few years away from seeing much of the standards ambiguity problem diassapear.

The complexity problem is a different matter...

IMS Testing Poster

Well, I have not been the most active blogger, but that doesn't mean I haven't been active talking about IMS testing. In fact, I just counted up how many IMS Testing Seminars Empirix did this year and the total number came out to 27 unique presentations to individuals representing over 75 different Labs and NOCs across 3 continents (so hopefully you can forgive me for not spending more time on the blog ;) ). And that is excluding the 7 or so webinars we did on IMS related topics (look at some of the past posts for links to many of these).

One common request I have received is to summary some of the book contents into a poster that one could hang on the wall of the lab. I think this is a great idea and this is something we will put together sometime early next year. Unfortunately there is a lot of content we could include, so we will need to focus on a specific area - i.e. testing IMS devices or testing IMS apps.

If anyone has any suggestions on what they would like to see include on this posted please post a comment here, or email me at chart@empirix.com.

I-CSCF does not have an ISC interface

Another realworld example of on the complexity of IMS - it seems we put in an ISC interface to the AS in I-CSCF DUT diagram (Figure 3.13). This should not be there and we made no reference to it in the text. Unfortunately we did not catch this one in time for the latest revision (R1).

Suprisingly no one noticed this error in either the Book Synopsis webinar we did with VON (link) or in the recent Testing for IMS Interoperability webinar that Gordon Eddy presented with Lightreading (link).

I must have fogotten to delete it when creating the diagram from the S-CSCF DUT example. Imagine all the extra work this could have created if this was a test spec given to QA. The sad thing is that this sort of thing happens all the time in real test environments.

Here is the correct image:

New revision coming soon

I apologize for the delay in sending books to many of you. We actually have gone through original printing of 1500 copies and have ordered a second run. Along with this second run we have made several spelling and formatting fixes. We should resume fufilling book requests with this new print run next week.

Good IMS Specifications Tracking Site

For those of us who do not have time to attend every 3GPP meeting or read all their reports, decent summaries of IMS Standards activities are provided here: http://www.hsc.com/IMSConsulting/Insight.aspx

HSC also appears to offer standards tracking services for a free as well.

Webinar synopsis of the book

Dan Teichman and I recently did a webinar with Pulver Media titled after the book. You can check out the archive here: http://webinars.pulvermedia.com/archives/2007/06/ensuring_a_qual.php.

It would tough to summarize 170 pages of content in 45 minutes, but we managed. We also received several good questions and had some good polls that I will share here this week.

Thoughts on Fixed Mobile Convergence (Figure 5.8)

We recently did a webinar on FMC with the Voice and Video over IP Quality Alliance (V2oIPQA). (if you missed it you can check out the webinar here: http://www.iian.ibeam.com/events/mult001/22800/)

In preparation for this webinar we decided to survey several of the major FMC vendors at NXTComm last week. In particular we were interested in seeing what their FMC architectures looked like:

• Is anyone following the official VCC standards, or were they using pre-VCC approaches?
• Are they deploying a single VCC AS, or were the CCCF and physically NDSF seperated?
• How were they interfacing to the mobile network?

It turns out everyone was claiming to support VCC although I did not have much time to verify the details. I also did not find any vendor deploying a seperate NDSF.

I was also interested in understanding if these vendors were incorporating CAP/MAP/SS7 interfaces directly into their products. It turns out they are not - everyone I spoke too was using external gateways to keep their VCC devices pure-IP. One of the IMS gateway vendors I talked to backed this up.

From a test perspective this makes things a lot easier as SS7 test equipment and CAP/MAP test cases are not required for testing the VCC device. However, it also means our Figure 5.8 on page 134 would be more accurate if the CAP/MAP interface coming from the VCC AS to the 2G RAN (to a MSC) should be going to a SGW instead of direct into the cloud.

On that note, we the 2G ad 3G RAN should really be labled as PLMNs instead, since we are talking about the switching infrastucture, not just the radio network components.