Ensuring Quality in IMS

IMS MARKET NEARS $1.2 BILLION

I was doing some research and came across this article from 2005 IMS MARKET NEARS $1.2 BILLION. 2.6 Billion by 2008? No way! Then I clicked the link and remembered this article was based on the IMS market research study I produced back in 2005.

So why did I predict the IMS market would be so huge back in 2005 and where is this $1.2 Billion in IMS equipment today?

First off I should note that my original definition of "IMS Infrastructure" was pretty liberal. It included big-ticket devices like Trunking Gateways and Gateway Controllers that fit cleanly into the IMS architecture but were not really anything new. It also included many SIP-based App Servers and SBC's that plug nicely into IMS and already existed. These pre-existing devices made up most of the forecast. The newly-designed CSCF's and HSS's were very a small part.

Today I would say CSCF's and HSS's are still a small part of the overall IMS/NGN market in terms of revenue. However, we see many service providers using these devices in serious lab tests and field trials. In most cases they are supporting pretty limited configurations - integrated CSCF's as opposed to distributed, and HSS's with low subscriber licenses.

I do think this will start to change in 2008 - especially after many of the recent conversations I have had with carriers in the past few months. You can see my What Happened to IMS? post for more details. Still, we are a long way off from $2.6 Billion. $50 Million in true-CSCF and HSS sales in 2008 would be a good start...

Why do I need to test if I have an SBC?

Nearly all the operators I have talked to who are deploying IMS networks are using SBC's (mainly from Acme Packet). I have noticed a trend where many of these operators, especially the smaller ones, are not doing much testing of the situations described in Chapter 4 because they have an SBC and "that's what the SBC does". As a reminder, the book covers the following topics in Chapter 4:

• Outage Recovery,
• Peer network floods, and
• Malicious attacks like DoS, Registration hijacking, and CallID spoofing

Yes, SBC's are designed to deal with many of these problems and they typically do a good job of it. But is your core network designed to deal with the SBC? SBCs are complex devices that require a lot of configuration. The goal of testing these scenarios is not to break the SBC, but to ensure the SBC is properly configured and optimized for your environment.

Using the Power Outage Restoration example, the SBC can throttle messages sent to the Core, but how do you know what your core can handle? What about the customized application you are running? Your system integrator will likely be very conservative and go with a low number, but this could lead to unnecessary capacity upgrades when they are not needed. A few relatively simple tests can help to answer these questions and keep your integrators/vendors honest.

First Poster Correction - Gq/Gq' Interface

I actually noticed this as soon as I got my first printed copy, but it was too late to correct in the first print run.

On the "IMS Core Testing Reference Guide" section, in the P-CSCF Test section, we show the P-CSCF to PDF interface as Gm. This should be Gq or Gq' as we describe in the call-out text. This corresponds to Figure 3.14 in the book where we illustrate it correctly. Here is the book graphic:

Gq is usually used to refer to the original 3GPP-wireless oriented interface to the PDF. Gq' usually refers to the ETSI TISPAN implemention and connection to the RACS. Since the ETSI spec transfer I have noticed more references to Gq' in the new and in-progress R8 specs.

3GPP TS 23.517 version 8.0.0 Release 8, section 12 has some high-level explanation.

IMS Poster is now available!

Dan Teichman, Empirix's Monitoring Product Marketing Manager, and I put together a new poster covering IMS Testing and Monitoring. You can sign up for the poster here http://www.empirix.com/imsposter.

One side of this poster focuses on Testing- highlighting an example IMS implementation and showing individual DUT diagrams for each individual IMS function and showing key test metrics for each.The other side shows a monitoring perspective – this section highlights key protocols used in a complex IMS implementation and shows key monitoring metrics for several IMS services. The content is based on the IMS book with some updates.

Revisions to the poster will be posted here. 

Here are a few low-resolution examples of what the poster looks like.