Ensuring Quality in IMS

I-CSCF does have an ISC interface (it is called Ma)?

In case you didn't see it, A couple of weeks ago Aayush posted a great comment on my post correction on Figure 3.13:

I-CSCF has to have an ISC interface. How else will it route incoming INVITE requests addressed to pre-configured sub-domain PSIs to the SIP-AS? Sometimes the I-CSCF sends an incoming INVITE directly to the AS, and the S-CSCF is not required in the signaling path for iFc processing. Similarly, the AS can also send requests to the I-CSCF directly.

I-CSCF and AS interaction is given in TS 23.228, Rel-8..Section 5.4.12.3 point c and Section 5.4.12.5 point c.

Gordon Beith (the Hammer G5 Product Manager and book co-author) and I did some research on this. Gordon found the following:

Actually, it [the AS to I-CSCF interface] was assigned an interface name, Ma, in R7.

In 23.002-710, it lists the following…

This interface between Interrogating-CSCF and the Application Servers (i.e. SIP Application Server, OSA Service Capability Server, or CAMEL IM-SSF) is used to forward SIP requests destined to a Public Service Identity hosted by an Application Server directly to the Application Server.

Details are described in TS 23.228 [34], subclause 5.4.12.

23.228-760 clause 5.4.12.2 states…

1. The HSS maintains the address information of the AS hosting the PSI for the "PSI user". In this case, the AS address information for the PSI is returned to the I‑CSCF in the location query response, in which case the I‑CSCF will forward the request directly to the AS hosting the PSI.

That’s about as much as it says in R8 as well.

We checked our notes and could not find any customer off hand who was implementing the "ISC" on the I-CSCF to check (this does not mean they aren't though). We wrote the book based on R7 which further adds to the confusion. We did make reference to the Ma interface from the VCC AS to the I-CSCF in Section 5.5.2 in the book and Figure 5.9, but not in the Section 3.3.2 that covers the I-CSCF. We will see if we can dig into this a bit more with some customers.

Anyone else out there implementing this spec?

More on SBC's

I came across this article on Acme Packet today where Seamus Horihan was defending the SBC as a stand-alone network element commenting: "If you look at the history of communications equipment, while many people have pursued [multi-function, all-in-one] 'God' boxes, none were ever bought or delivered," he said.

I completely agree with Seamus - every IMS operator I have spoken with, and most of the major vendors, are using independant, integrated SBC's in their network. In fact almost all of them are using Acme - independant of who their core provider was (NSN, Ericsson, ALU, etc.). So it seems the SBC's have made a strong foothold in these arly IMS.

However, I found the 'God' box comment interesting - if anything SBC's are becomming 'God' boxes of IMS, encompassing many functions including the A-BGF, C-BGF, I-BGF, IBCF, IWF, P-CSCF, I-CSCF, SEG, PDF/SPDF, and or RACF in many cases. Most SBC vendors offer a distributed SBC architecure that breaks these functions out, but it seems most operators are choosing an integrated approach in these early stages of real deployments.

From a quality perspective this makes implementation easy - fewer components and interfaces means there is less you have to test (see my post on Why Test if I have a SBC from last week for more info on SBC testing). Verifying the configuration of one device is easier than verifying the configurations of 5. But is also means less flexibility for later and more trust in your SBC vendor and system integrator. It is difficult to peer inside the inner workings of the SBC to see what it is really doing, which is fine until something goes wrong. Time will tell how scalable this approach is.

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 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.

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: