Okay, after reading Steve Job's macworld 2007 report by engadget on the iPhone, I really don't feel like talking about bellhead technology, but here goes..
Just about when a set of specifications gets too ambitious and onerous, a vendor’s engineering department concludes that they really need something ‘leaner’ for their particular market. At the same time the marketing department wants to ride the wave of popularity by associating their ‘leaner’ product to a well known acronym. As a result, you get xxx-Ready or xxx-Lite, where the former effectively means ‘we don’t support xxx yet, but we sure can, since our product has great open interfaces, and has architected by the best architects in the world, believe us’ and the latter effectively means ‘we sliced and diced xxx, selected the parts we need, threw the others away, and it may not really be a 100% compliant to xxx but it is 100% complaint if you use us and our partners exclusively’.
‘IMS-Lite’ is a term that is floating around in the market today and is being used by several vendors to describe a ‘subset’ of functionality as well as ‘tweaks’ to the base specs to suit their needs. Of course, there is no standard for IMS-lite. If there were, it would be as complex as the base IMS specs itself. Different vendors/operators have different takes on IMS-Lite, depending on which network is their primary deployment requirement. Most of the IMS-lite terminology comes for non-cellular operators who don’t want to carry all the baggage of the cellular world, but want to be able to interconnect. It is interesting to note that the core specs actually make most of the point stated below optional, but all the examples and deployments use them, since they are deployed by cellular operators, and hence one gets the feel that all of the features must be supported.
Here is a brief on various 'thoughts' on what an IMS-Lite should look like (not specific to any vendor):
- Merge the P, C and I CSCF into one entity, call it the ‘Call Router’ if you wish. Even though they are logical functions, the interactions between them are one too many – let vendors decide how they implement the internal functions, as long as externally, they support SIP and DIAMETER. This itself reduces the specs significantly.
- Ditch the Initial Filter criteria – the iFC is the XML spec and workflow of how a CSCF selects an appropriate AS and/or performs local services like call barring. How does it matter how a filter is implemented ? Let it be a vendor decision
- Abstract the HSS - one of the biggest pain points of non cellular operators, such as enterprises, to connect with the IMS is that there is no way they are willing to share their user data and have it hosted in an operator’s network. So allow data federation, and allow a mechanism where the ‘central data store’ could be located in either the master or the access network and define a security protocol between the master and access network to allow for such federation
- Kill the ‘OSA-SCS’ and ‘IM-SSF’ application servers – which magically convert OSA and CAMEL services magically to SIP. I don’t know how such magic can effectively happen. Non SIP services don’t have a 1-1 mapping with SIP flows. IF one needs to provide non SIP services, hand the call off to a terminating SIP UA server that knows how to maintain service state of the non-SIP protocol on the other side. In other words, the ‘OSA-SCS’ and ‘IM-SSF’ define functionality that the gateway AS will do anyway.
- Move the concept of ‘Home’ and ‘Visited’ to an appendix. Unless it is an expensive over the air proposition, it doesn’t really matter, from the signaling plane, if I am calling from Tahoe and my ‘home’ network is in Timbuktoo. From a media perspective, however, it does matter, especially if it MUST route through a media node for bandwidth allocation and Legal Intercept. These are, however, public operator requirements and are mandated in enterprises, for example.
- When a UE registers, have it negotiate how it will report charging. The reason is simple – IMS defines an extensive distributed method for charging for on-line and off-line systems. In the case that the network can guarantee that all calls and/or media will flow through it’s nodes, the entire charging participation from end nodes reduces.
- The entire USIM/ISIM algorithms need to be pushed to an appendix. How one computes its ‘public’ identity is a network matter. For example, enterprise phones are ‘provisioned’ with static identities – there is no SIM card.
- Make 33.203 an option, not strongly referenced. Instead do a good job of 33.978. In other words, don’t require implementations to exchange a two way IPSEC SA with the P-CSCF. Many networks can depend on the underlying layer’s security. 33.978, which is called ‘Early registration’ is a start, but for example, it does not yet support WLAN based UE authentication
- Specify HTTP/Digest as another allowable authentication method –it works just fine assuming that a lower layer provides encryption, which is very common with enterprises
- For lord’s sake, provide examples of simple call flows without preconditions in 24.228 (The core IMS architecture document)! For example, did you realize why UPDATE is needed before the 180 ringing on the remote side ? That is to ensure that the remote phone does not ring its user and then have the phone disconnected because bandwidth could not be reserved.
But wait, what is it that you say “What I am proposing is what already exists today in Wireline SIP/VoIP deployments and that is not really IMS ?”. Gee maybe you are right. And maybe that is what IMS-lite is ? But seriously, I think IMS would benefit from abstracting out a lot of the celluar specific procedures from its core specifications, if it now desires to be used across multiple access stratums.