Search This Blog

Friday, September 22, 2006

A-IMS from Verizon and Buddies: A Good thing as I see it

Ever since ‘A-IMS’ was announced by Verizon, some months ago, blogs and columns have mushroomed all around with comments ranging from ‘Will this set back IMS deployments for several years??’ to ‘I just completed reading the specifications and it looks interesting’

Here is how I see it: Think of A-IMS as a deployable product packaging of the standards that 3GPP/3GPP2 have been creating. Read it again: A-IMS as a deployable product packaging. In other words, Verizon (and buddies) have looked at existing specifications and have asked “For it to be successfully deployed in MY NETWORK, what do we need?” and have proceed to fill in the ‘blanks’.

And this is a great thing. Left to themselves, standards always aim for utopia. In the mean time, vendors suffer deployment blues because certain ‘real’ problems are left open, to be addressed later. Most architects will agree that a live deployment only uses 30% of a utopian network design, and this exactly why we always have vendor incompatibilities as standards evolve (ever worked with a Cisco IAD in the early SIP days?).

The nice thing about A-IMS is that because it is vendor controlled and not a standards consortium, they are not forced to taking the ‘most generic path’. For example, they have taken a firm stand and have detailed procedures on not only what a Policy Format should look like, but also What it should contain.

Not to be left behind, another set of operators/vendors have recently gotten together to form what they call NGMN to take IMS towards realization along a path that they think is correct. At first glance, this may give one the idea that this will result in architectural forks. Get real buddy – Even with only 3GPP/2 as the only standards, different vendor OEM products have a tough time talking to each other. I remember doing an end-end IMS deployment consulting for an operator – when we spoke to the vendors, each one pitched an “end-end” network fully comprising of their own products (or partners). So when I asked them “So are you fully standards compliant?”, the common answer was “Ofcourse. But we can guarantee that only if you use our products end-end”. So there.

The reason I like A-IMS is that this was done with an immediate deployment concerns. Matters that have not been resolved yet in 3GPP have been tackled, and have been given due priority, even it it means a solution that suits Verizon’s existing EVDO network. It’s a stake in the ground.

So without much ado, some of the major A-IMS ‘additions’ and my interpretations are:

Policy Manager – While 3GPP defines the interfaces (Go) and the envelope formats for policy, it does not outline when a policy kicks in, what is the SLA to be adhered to, what are the corrective actions. The A-IMS policy manager takes the standard 3G PDF and extends it with realizations.

Application Manager – A perfect example of product packaging. A-IMS has lumped together all the control ‘-F’ functions together (S/P/I-CSCF) and called it the Application Manager (AM). It’s an entity that controls session state. This is also why A-IMS says they have ‘simplified’ the network. Actually, that is quite untrue – they have simply shown a realization while 3G leaves it to logical functions. So in A-IMS speak, this one node routes, validates, filters, inspects and finally hands over messages to application servers.

Services Data Manager (SDM) – The SDM is the A-IMS version of the ‘universal data repository’. In many ways, it is like the proposes ‘GUP’ HSS profile (Global User Profile). In essence, it acts as not only a repository of data for standard HSS services, but it also allows proprietary data to be stored in it via fixed interfaces that are accessible by 3rd party application servers. This eases data management for the network.

Bearer Manager (BM) – This has been one of my biggest pain points with the state of standards today. As it stands today, while control plane policing is defined, its relation to bearer plan is severely lacking. Specifically, in 3G, since for an invoked service, signaling and media goes in different paths (eg RTP through GGSN, SIP through CSCFs), one needs to be able to specify policies that identify and correlate streams at ‘business logic’ level, not just ‘message level, via embedded identifiers’. A-IMS takes a step forward and specifies rules/associations for managing the entire service stream as a single entity. To purists, this means that A-IMS is stepping into defining ‘what a service could be’ – and I like it. I like to know what a service is, I like the concept of a ‘Service Identifier’ , and I hate it when people compare services to a generic programming language, as far as deployment realities go.

Breaking multi-level authentication – One of the goals of 3G was to isolate layers from each other, so that 3G could work across all access networks. While this is architecturally great , this also induced performance problems, if no one layer could assume functionality of another. This was sorely felt at security negotiations with RAN, IP-CAN, and IMS all performing their own authentication and security negotiations. A-IMS has put a stake in the ground, selecting the EAP framework and has specified mechanisms of how one set of layer keys can be used to ‘compute’ keys for other layers, decreasing latency and making it easier to perform ‘single sign on’ deployments (FYI, EAP is used in the WiMAX Network Ref. Model as well)

The hype of ‘SIP and non-SIP applications’ – This is the most commonly quoted ‘enhancement’. In IMS, the AS only sees ‘ISC’ (SIP) and non-SIP to SIP conversion is done by adaptors. The problem is that no one really specified how the adaptations would be done – sort of a ‘fabulous goal – tell us how to do this conversion too, please’. A-IMS, instead introduces a “Services Broker” – which along with the App. Manager and Policy Manager can interface to both SIP and non SIP interfaces directly. In addition, the “Services Broker” is also a feature interaction manager (much needed).

Platform security threats – one of the areas sorely missing from 3G, is any reccomendation on how to prevent platform level attacks like Ddos, DoS, MOTM and others. A-IMS again takes a stab at this and specifies a unified model which they recommend that covers security from a 3 dimensional model - I think that’s the X.805 format from Bellcore - how threat, destruction, corruption, removal, disclosure, interruption affect Access control, authentication, non repudiation, data confidentiality, communication security, data integrity, availability, privacy for End user, Control layer, bearer layer and management layer

So all in all, I like A-IMS. I don’t care if it created a fork in 3G standards. Chances are that Verizon, Lucent, Motorola, Qualcomm and Nortel will push a lot of these ‘filled in gaps’ into the standards and this will fuel the standards more. Speaking of NGMN (from China Mobile, NTT Docomo, KPN, Vodafone, Orange, Sprint-Nextel etc) I haven’t seen the details yet. But I hope they fill in more gaps as well.


  1. Hi

    Great post and very interesting analysis. I'm afraid that IMS is becoming a chaos, due to all interoperability issues and propietary solutions at the edges. All the vendors want to evolve their own platforms to be 3GPP compliant... with their own products, as you say.

    Interesting the multi-level authentication. One of the most challenges when heterogeneous access networks are used is the delay due to new authentication. Also in handovers. Have you found in the document data about latency time or related to this issue?


  2. Interesting indeed. I think it is generous of Verizon to publish their internal implementation spec, and brave of all those vendors to tell us what they are going to do, since that has to be based on implementation plans and gives all the other guys in Standards an advance warning to allow them to take pot shots at it (sorry, thats how standards works). What I find most interesting is that a lot of what A-IMS defines is actually NOT about IMS at all, but about the bits that reside around the edge of IMS. These same functions (policy, authentication, bandwidth management) can be applied to any Service Enabling architecture, including access to the internet for a vertical third party service.

    I also find it interesting that A-IMS seems to be a rip off of a lot of stuff that MSF are doing (which Verizon are members of). It's easy to innovate (sic.) when you nicjk someone else's ideas.

  3. Does Verizon give any details about the policy manager ? Are there any standard docs available in this regard, just curious

  4. Does Verizon give any details about the policy manager ? Are there any standard docs available in this regard, just curious

  5. Unfortunately not. It seems Verizon and partners keep the specs close to their heart, so to speak.

  6. I notice that Cisco notoriously absent from mention in your article as one of the partners developing this solution for VzW, aside from the snide remark about the old Cisco IAD. Since Cisco is first in the "Acknowlegements" section of the A-IMS Architecture doc (June 2006) I can only assume this is intentional.

    In reality, Cisco is responsible for implementation of the Bearer Manager portion of the solution that you seem to like so well.

    And thank God that Cisco is involved - otherwise A-IMS would wind up with same problems, shortfalls, and oversights as IMS. Because that is what happens when telecom network people try to write a data spec.

  7. You noticed correctly. However, I have no interest ,gain, nor loss in either mentioning or not mentioning Cisco. Looks like I just missed mentioning their name. Sorry I couldn't offer a more climactic response. I am glad you appreciate Cisco's role in this.