IMS Roundup

The IP Multimedia Subsystem (IMS) space is confused. Heavy Reading Senior Analyst Graham Finnie was writing in early January of “anarchy” among application layer vendors. IMS itself is a peculiar animal. Born a wireless specification, it has splashed around in the telco world and is now migrating into the cable industry via PacketCable 2.0 and cable’s own wireless and business services initiatives. Is the IMS discussion now moving from architecture to services and applications? How does IMS relate to Web services? Are vendors dropping the hype? What’s the next step? We’ve rounded up the views of several experts and driven them through the following pages to help readers draw their own conclusions to these and related questions. Beyond Hype, Business Services Rise Lior Weiss is VP for media gateway business line at Audio Codes, a company that provides voice over packet-related media gateway, server and processing technologies to OEMs, network equipment providers and system integrators.

How would you characterize cable’s interaction with IMS?

Cable operators are struggling with the benefits and disadvantages of IMS. One of IMS’s best capabilities is its openness and standardization, which will help drive down network costs. On the other hand, PacketCable has been a great tool for the operators to actually close the network and to allow them a narrowed-down, select base of well-baked solutions and suppliers from which to chose.

MSOs are trying to pick their battles and to implement IMS only when necessary—for example, when introducing new services that are not very feasible with the current PacketCable specification. And that primarily leads to services that involve mobile carriers or commercial services to enterprises.

Is North America diverging from Europe in this area?

Traditionally, the Europeans have been less concerned about PacketCable. If you take UPC, for example, we deploy (media gateways) there with Nortel, based on a nonPacketCable architecture—basically H.248-based softswitch. Also, Siemens, which is very active with small European MSOs, still deploy a lot of V5.2 solutions there, which is also nonPacketCable-related.

What IMS applications are getting the most attention?

In terms of industry buzz and hype, it’s probably fixed-mobile convergence. I think MSOs are truly occupied with business services, however.

Within the IMS framework?

Fair question. This is where you begin to get your hybrids. The extent to which you define a certain deployment or architecture as IMS is left to the interpretation of the reader. But those business services often are outside the scope of PacketCable. Whether or not they are 100 percent compliant with IMS is another question.

Which services do you have in mind?

Enterprise-hosted services are very much SIP (session initiation protocol)-oriented. And the vendor ecosystem that the cable operators are looking at is definitely one that claims to have IMS components. A longer list would include such things as hosted PBX (private branch exchange) solutions, IP (Internet protocol) centrex, unified communications, collaboration, video conferencing, etc. PacketCable 2.0 and IMS: CableLabs Speaks CableLabs has planned a four-part series to help educate the industry on PacketCable 2.0. Here is a section from the first overview article, written by CableLabs staffers Kevin Johns, project director, PacketCable Communication Protocols, and Eric Rosenfeld, director, PacketCable Architecture.

…PacketCable 2.0 is based upon the Third Generation Partnership Project (3GPP) IP Multimedia Subsystem (IMS). IMS provides a framework for the delivery of IP Multimedia services (i.e., audio, video, text, chat) by defining an architecture that includes component behavior and protocols. The IMS was developed to meet the requirements of the Groupe Speciale Mobile (GSM) wireless industry. IMS has become the Session Initiation Protocol (SIP) service delivery platform of choice for many telecommunication industry sectors, such as wireless, DSL, and cable. However, IMS was developed for the GSM industry, which is a different business, a different service, and has different operational requirements from cable.



In incorporating the IMS into PacketCable 2.0, the cable industry has accelerated the development of PacketCable specifications and the availability of products and services while avoiding re-inventing the SIP service platform. However, IMS currently doesn’t meet all of the cable industry’s requirements. As such, CableLabs is working with 3GPP to enhance the IMS to meet the functional requirements of the cable industry. The objective is to tune IMS to support the cable industry’s needs, and then focus on defining value-added applications. Migration Paths, Business Services, and IMS Service Control Interface Jonathan Rosenberg is a Cisco Systems Fellow, a co-author of the session initiation protocol (SIP), and author of SIP for presence and IM (SIMPLE) and other key protocols. He is active in the Internet Engineering Task Force (IETF) and the Internet Architecture Board (IAB).

You have contended that a public switched telephone network (PSTN) bypass could initiate  a migration to IMS/SIP. But operators don’t seem to be rushing toward that option. Is that still a good place to start?

It is still what I think they’re planning on doing, and I’m aware of ongoing processes to do vendor selection and roll out plans and testing.

However, I think that cable operators have been caught up in its own success. Subscriber growth in the voice business has been so good and the service so successful that, from my observation, most of the operators have been spending their time just building up that existing network, growing their capacity, growing their ability to operate the network, adding elements as necessary, and improving scale on the existing system. Those are clearly the most pressing problems.

Things like the PTSN bypass are not functional or scale improvements at all. They are cost savings, which is good, but it’s not at the top of the list.

What else is driving operators’ interest?

Commercial services are one of their next priorities as a SIP-based IMS type of service, which is going to require the rollout of some of the IMS infrastructure to support. We talked about that as a second step, but for a lot of these operators, it may in fact precede the PSTN interconnect.

Then there’s fixed-mobile convergence. But that’s a real challenging service to get working, mostly because of the business and organizational relationships between the cellular operators and the cable operators.

Are some of these advanced services better handled in a Web services descriptive language (WSDL) framework?

WSDL remains a piece of the total picture of the services that a lot of cable operators are rolling out. There’s a whole other set of services not related to real-time communications, such as Web, email, and voice and video streaming, which are making use of Web services components.

There’s certainly a role for this technology even in the provision of real-time communications. You could link voice applications to content and information that would normally be accessible through Web 2.0 type interfaces. The application server layer of IMS is well-suited to interface to Web services components.

Is there a logical division of labor between IMS and Web services?

I don’t think it’s one vs. the other. But there are ways to leverage one technology to help the other. For example, Web services are frequently used for transactions systems and database access. IMS applications can use those interfaces. Other possibilities include single sign-on and identity management.

What are your expectations for IMS over the next 12 months?

I think it will be something that gets introduced in stages. In our discussions with operators, there remains a strong interest in rolling out pieces of the IMS architecture, a bit at a time, coupled to particular services and applications that they want to put in their network. You need to view IMS as an enabler, not as a thing in itself. It’s the services that it supports that bring the revenue that ultimately are the justification for its introduction. And it’s those services that drive individual pieces.

Which pieces do you have in mind?

One of the things that we’ve seen a lot of demand for, and which we’ve added support for in our softswitch product, is what I would label as probably the single most important piece of IMS to roll into your network. That’s the ISC (IMS Service Control) interface. It is basically the interface between the main IMS SIP component, called the S-CFCS (serving call session control function) and application servers. That interface provides a well-defined set of roles between what the infrastructure does and what the application does, and it provides a well-known way for that infrastructure to invoke an application at the beginning of a call. 10 Tips for Evaluating IMS Vendors (From a Vendor) Tom Buttermore is general manager of Cable Solutions at Nortel, one of many vendors offering solutions in the IMS space. Each has its own approach for helping carriers and operators navigate and adopt IMS-related technologies. Buttermore was previously VP of data engineering and operations for Adelphia Communications.

1. Ensure the IMS solution supports protocols and industry standards.

IMS is generally a loose term referring to the common services architecture initially defined for GSM/UMTS (universal mobile telecommunications system), which encompasses all service providers, including cable providers, code division multiple access (CDMA) wireless providers, Internet service providers (ISPs), and traditional telephony providers.

The IMS vendor you choose should support all domains, while simultaneously supporting industry standards on the same core infrastructure.

2. Double-check that the IMS solution includes an architectural overview of CSCF, home subscriber server (HSS) and application server(s).

The modular design of IMS architecture allows you to leverage elements in the network across many services. If a vendor tells you certain elements have been conveniently merged into a single box, you should be concerned about growth pains, geographic distribution and proprietary engineering optimizations.

3. Confirm the systems integration will run smoothly.

Minimal or not, there are always integration issues to address. You must mix equipment from an array of vendors to create a best-of-breed solution and to evolve that solution over time. A vendor who glosses over integration issues may not have the depth of resources or commitment to help you address them.

4. Look for SIP expertise.

The IMS network depends on efficiency and interoperability of SIP messages. Ask prospective vendors to detail their SIP deployment and integration experience.

5. Beware of solutions that don’t support billing.

Although near-term plans might be to offer free trials, don’t be led astray by solutions that will need major retrofits when you want to start generating direct revenue. Any IMS strategy must include a solid plan for supporting subscription-based, usage-based and tiered billing.

6. Ask about support for the latest industry innovations.

Ask prospective vendors if their solutions will give you opportunity to comply with the Advanced Telecommunications Computing Architecture (ATCA) standard, but don’t stop there—not all ATCA platforms are built equally.

7. Validate the scalability of the IMS solution.

If you ask about scalability and get a finite number or infinity, beware! There are too many variables to make either claim, and scalability depends on much more than the capacity of a server to support X number of subscribers. Instead, take into consideration service, load, cost, geographic and technology scalability.

8. Reliable networks are essential.

Ask prospective vendors to describe the processes they use for modular and targeted testing, system and network integration. The rigor of these processes will say a lot about how their solution is likely to perform in the real world.

9. Evaluate the application offerings.

Survey the IMS vendor landscape to be certain that you have identified vendors that have service deployment experience and can enable the services tailored for your IMS strategy. Ask IMS vendors about their set of ready-to-go applications.

10. Inquire about vendor interoperability.

IMS vendors know this is important, so if they’re smart, they will join up with technology partners that presumably support their products and vice versa. However, participation in such an alliance is no genuine guarantee of interoperability; be sure to ask for their successes to date. Interoperability, SDPs and Web Services Indu Kodukula is VP, service delivery platform,and Stephane Maes is senior director, service delivery platform, for Oracle, the enterprise software giant.

What’s your take on the cable industry’s adoption of IMS/SIP via PacketCable 2.0?

The adoption and standardization of SIP in the cable industry by the PacketCable 2.0 initiatives is very positive. However, the specific approach and network architecture PacketCable 2.0 has defined differ from the 3GPP/3GPP2 specifications. Therefore, resulting implementations have the potential for interop and inter-networking challenges. Our recommendation is to implement these systems in a future-proof manner, using a standards-based, service delivery platform (SDP), for example.

Which IMS-specific services seem to have risen to the top?

The current focus on IMS or pre-IMS deployments appears to be the implementation of traditional telephony services on an IMS core. For example, service providers are implementing voice over IP (VoIP), presence, presence-aware messaging, and multi-media communications such as voice and video mail. Some of the most innovative service providers are using a standards-based SDP to implement the IMS service layer and enable Internet or Web 2.0 applications to run in an IMS environment.

Are some of these services better handled in a Web services framework?

When combined with other IT standards required for the implementation of core service components and building blocks (such as J2EE, SIP Servlets, Enablers), Web services provide all the capabilities required to build, integrate, customize, deploy and generate revenue for complex next-generation data services.

Is there a logical division of labor between IMS and Web services?

Absolutely. The IMS specifications provide a tremendous amount of detail on transport and session control layer specifications. They acknowledge, but do not specify in detail, the behavior of the service layer. The evolution of the Internet and the arrival of Web 2.0 have resulted in a clear maturation of Internet standards, such as Java EE, Web services and service-oriented architecture (SOA). Service providers can now implement even the most demanding telecommunications services, such as VoIP or call control, on a platform that leverages Internet standards.

It’s also worthwhile to note that the IMS and Web services layers should not be mixed in the other direction. In particular, SOA and Web services-based approaches are not yet appropriate to support the implementation of the session control layer or the transport layers.

What are your near-term expectations for PacketCable 2.0/IMS? For Web services?

There is significant momentum in initial trials or deployments of IMS networks or services, including PacketCable 2.0. However, the initial investment required and the lack of a large portfolio of revenue-generating services in an IMS environment are causing operators to take a cautious approach toward full-scale IMS deployments. More pre-IMS deployments, such as VoIP, are likely to take place over the next 12 months as operators adopt the concepts from IMS in an incremental fashion, without rolling out a full-scale IMS architecture. As such, service providers are particularly concerned about future-proofing their investments.

Web services and SOA technologies are reaching maturity with a complete stack of standard specifications. Software companies are improving SOA technologies to fulfill carrier-grade performance. With the commercial availability of standards-based SDPs, we expect that trend to accelerate.