|
Mobile & Wireless
Leverage and Extend
Verizon Wireless’ Ed Salas Speaks out about Enhancing IMS
by Sean Buckley
Ed Salas, VP of Network Planning for Verizon Wireless sees a bright
future for IMS. However, after evaluating the initial IMS standard, he
realized there were a lot of elements that were not addressed. The
solution Verizon Wireless has proposed, along with its key vendor
partners, is A-IMS (Advances to IMS) which calls for enhancements to the initial IMS standard. Salas recently sat down with Sean Buckley, Editor
of Telecommunications® to discuss A-IMS and its role in the converged IP
network.
Q. What drove Verizon Wireless and your vendor partners to come up
with the A-IMS architecture?
A. As we were looking at our EVDO Rev A. deployment plans and doing
more work in the core, I wanted to do a deeper dive on IMS with my
team. Over the course of a year, we were driving questions about
implementation: were all of the issues we saw in an IMS architecture
resolved or not? We emerged with a whole lot more questions than
answers in regards to IMS. Not that that anything was necessarily bad
about IMS. It was in fact great, but we just saw a significant amount of
complexity, given the 50 plus functions and growing, 30 plus interfaces
specified and growing. Also, we saw some areas that were not
addressed such as end-to-end security and managing the customer
experience on an end-to-end basis. Specifically, one area of concern to
me was the need to manage not only SIP-based services, but also non
SIP-based applications of which we have a lot in Verizon Wireless, as do
other service providers. What we did was pull together a group of our
suppliers -- including Lucent, Nortel, Motorola, Qualcomm and Cisco -- and
created an internal task force to address the generic operator challenges
and issues around IMS. We have spent the last year with this group in in-
depth discussions to come up with an approach that extends and grows
the IMS standards to address some of the challenges that we identified.
Q. Does Verizon Wireless plan to adopt elements of A-IMS?
A. We tried to make the IMS architecture more operator friendly, so we
bundled a lot more of the IMS functions in what we think are sensible
ways. At the end of the day, when we build a network that supports a
robust set of IP services, we’re going to have technicians running the
network, so we need to have boxes and technology that can be readily
managed, scale, and provide all of the attributes we need to deliver a
carrier grade service. Our intent is to take to take this 300-page
architecture and specification document not only to 3GPP2, but also to
3GPP and the IETF because we think that the issues we are addressing
are agnostic to the access technology. A-IMS addresses common issues
that all carriers that want to manage IP-based services have to face.
Q. Are you currently working with these standards bodies?
A. We have been talking to a number of key participants from the
standards bodies. We had behind the scenes discussions with suppliers
such as Nokia, Ericsson, and Alcatel, and have talked to global operators
who we think are facing a lot of the same issues we see. Thus far, we
have a fair amount people resonating to the problems that we observed,
and our approach as defined in this work. Our intent is not to dislocate
the IMS implementations to date. This work accommodates all of that.
Really, we want to help solve some of the basic issues that we think will
be important to operators.
Q. Tell me about how A-IMS addresses the complexities of IMS?
A. The beauty of IMS is that it’s flexible, but the downside of that
flexibility is that it’s complex to manage. It’s conceivable that you could
have as many permutations as there are operators or suppliers out
there. I did not view IMS as an island implementation. What was
important to me as I looked at my core network, was not only the notion of
interoperability in my network between suppliers, but also between
carriers (wireline, wireless, or cable) as we look to move applications
between our respective networks. One of the core applications that we
were solving for was an implementation of VoIP. We have a robust circuit
switched voice network today in our 1XRTT network, but with Rev A we
will have all of the tools we need to evolve to carrier grade VoIP. We
needed an architecture that would support the voice product not only
across Verizon Wireless’ network, but also between other carriers. The
challenge is that if everyone implements their own IMS or SIP-based
service sets, we could end up creating a lot of different islands in the
same way that you might have the inability of a Skype client to interact
with a Vonage client today. If you want to preserve for the customer
that seamlessness, we need to do things in a more common fashion. It
does not mean we can’t compete, but it means at a foundation level,
some of the implementations and methods need to be somewhat aligned.
This is not terribly different than when we were developing SS7 or ISUP --
only now we are doing it for the IP world.
Q. Security is another major theme of A-IMS. Tell me about how A-IMS
addresses security?
A. Security is not addressed in the original body of work that was IMS.
Today, we address security standard and on an application-by-
application basis. We needed to think about security on an end-to-end
basis. As we move into the IP environment, we need to manage
application security, core transport/network security, and access
security. If you want to preserve the customer experience, we know if
you implement all of these security methods in piece meal, you will
degrade the customer’s experience by having overwhelming security. We
needed to think about end-to-end security and build an architecture
that would accommodate a sensible implementation.
Q. Another key driver of A-IMS is to support SIP and non-SIP services.
Tell me about that construct?
A. A key driver of A-IMS along with VoIP is to deal with non-SIP
services. IMS was based on the ability to provide SIP-based services. If
you look at the Verizon Wireless product suite, a lot of our data products
(i.e. Brew applications, our V-Cast audio and video applications) are non-
SIP in nature. What we needed was an architecture that accommodated
all of those services as well as the new SIP-based services and
coordinates and manages them accordingly. We don’t think the customer
is going to care what protocol their services are supported on, so we
need this to look and feel like it’s one thing from a user experience
standpoint.
Q. What feedback have you gotten from other operators and
organizations looking at IMS?
A. Generally speaking, when we talk at the engineering level to other
carriers, we have a high degree of people resonating to the message.
Because the work was not fully baked we could not give them
something, and we are now in a position to do that now. If you talk to
operators in Europe, which are 3GPP-centric in nature, their UMTS/HSDPA
networks are hybrid TDM/IP networks, so their need to solve for VoIP
applications is less urgent than mine is in an EVDO environment. A-IMS
might be more relevant to their LTE (Long Term Evolution) work.
Alternatively, for the WiMAX and MSO communities that are trying to deal
with solving VoIP challenges, we figured if we could solve for VoIP a lot
of the other applications fall into line.
Q. Does Verizon Wireless’ plan to apply the principles of A-IMS in its own
network?
A. We want to have these principles we integrated into this work
respected. Having said that we really want to drive this into the
standards process because if we end up doing something unilaterally it
will defeat the effect we are trying to achieve, which is seamlessness.
Because this is a highly modular architecture we’ll see elements of this
evolve and get represented in our own network over time. However, the
real goodness of this will only happen when we get a broader community
to adopt it.
|
