The Role of Application Servers in IMS

Key elements for future telecom value: * Capabilities * Challenges * Platforms

September 21, 2006

18 Min Read
The Role of Application Servers in IMS

Open standards are becoming the bedrock of next-generation networks (NGNs). On the software side, they're manifested by the likes of IP Multimedia Subsystem (IMS) and TISPAN – standardized network/service architectures aimed at creating a platform for the development and rollout of all types of services over any NGN access infrastructure. On the hardware side, open standards are exemplified by the Advanced Telecommunications Computing Architecture (ATCA) platform specification. But right in the middle of all of this are application servers (ASs), the subject of this report.

Application servers aren’t exactly new, as they have been around for years in legacy AIN-type services and mobile networks. But opening them up in a big way to all types of service and to all types of service-software developer most certainly is.

Open standards for application servers may sound straightforward, but it isn’t. The IMS/TISPAN ASs play many key roles, and different ASs are needed for a multitude of different functions. Further, something is needed to orchestrate them into a properly functioning whole. This is inherently complicated because of the immense flexibility that is the whole point of IMS/TISPAN, the convergence of multiple service types, and the huge physical scale on which the servers will have to work to handle millions of customers. Software and hardware are both going to be crucial.

Since IMS itself is still at an early stage of its evolution, there are plenty of open issues and challenges ahead, and, not surprisingly, a lot of questions for application servers in terms of the requirements they will have to meet and the best ways of doing so. And there are higher-level issues, such as applications transition strategies – for example, what’s realistically possible as carriers move from legacy networks and service architectures to NGNs?

The basics of IMS and TISPAN have been covered in several previous Light Reading Reports – see, for example, Tispan: IMS Plus and The Role of IMS in PSTN-to-VOIP Migration – so this report leaps straight into the topic of application servers. But, since the detail of how application servers fit into IMS and TISPAN is important, there is a summary of some key points attached as the last page of this report.

Here’s a hyperlinked contents list to how this report covers these issues:

Webinar

This report is based on a Webinar, The Role of Application Servers in IMS, moderated by Graham Finnie, Senior Analyst, Heavy Reading, and sponsored by Alcatel (NYSE: ALA; Paris: CGEP:PA), NetCentrex SA , and Radisys Corp. (Nasdaq: RSYS). An archive of the Webinar may be viewed free of charge by clicking here.

Related Webinar archives:

— Tim Hills is a freelance telecommunications writer and journalist. He's a regular author of Light Reading reports.

Next Page: Creating Applications With Application Servers

Using ASs in the converged IMS/TISPAN NGN architecture moves service/network structures away from the traditional vertical integration – a series of separate service/network silos (such as voice/PSTN) – towards a more horizontal structure, as shown in Figure 1.

“The commonness of the services and the commonness of the enablers of the services on the converged network really do change your view of how you create, define, and launch new services,” says Brian Mahony, VP of Marketing for NetCentrex SA . “In an IMS world you now have common services that can be deployed across any network through converged, ubiquitous CPE, including mobile phone, the PC, TV, and traditional enterprise phones. You can do that now you have these objects that are enabled and used by various services from multiple vendors.”

Figure 2 shows and example of how a specific service (video surveillance) would work in this environment.

In this example, the video camera detects a movement and sends a recorded video alert via HTTP. The customer’s mobile device in turn gets a video phone call via SIP, and the customer sees the recorded video showing the movement that triggered the alert. The customer can then connect to the live video feed of the camera by pressing a key on his mobile device.

Specific service events include:

  • SIP registrations: User phone registers to the S-CSCF

    • SIP callflow: AS establishes a call leg to the user phone; AS establishes a call leg to the MRF; RTP is negotiated and established between the user phone and the MRF

    • VXML callflow: MRF downloads VXML script that has been created/adapted by the AS

      As with any new and complex technology, there are inevitably going to be challenges in deploying a full IMS and TISPAN framework, and telcos and service providers will have to devise a transition strategy. One approach, according to NetCentrex’s Mahony, could be:

    • Evolve existing SIP architecture toward TISPAN/IMS because there are some differences. For example, on the telephony side this would mean evolving Class 5 Application Servers into fully standardized IMS Application Servers supporting the ISC Interface to the various CSCFs. Also, it is essential to ensure interworking between ASs and key TISPAN/IMS core components, such as P/I/S/-CSCF, session border controller (SBC), and interworking equipment.

    • Provide integration with IMS service enablers. This means supporting interworking with IMS service enablers such as Instant Messaging, Presence, Group Management, and so on, as these are capabilities and features that can be accessed by the various application servers. Providing the tight integration and testing for those devices is also important.

    • Provide tight integration with Service Delivery Platforms (SDPs). SDPs will play an important role, as IMS will involve a lot of moving parts from different vendors, and it will be important to integrate them – not only for service definition, but for rollout and deployment and for integration with the back-office OSS, rating, charging and billing systems, and so on. SDPs can provide pre-integration of such key solution components for fast deployment. It is also important to develop SOAP provisioning APIs for AS services.

    • Figure 3shows what such a transition might look like in terms of the boxes and the application servers deployed in a network moving towards IMS and TISPAN.

      “To take a telephony example, today you may have a Class 5 softswitch,” says Mahony. “That is getting combined into the application server layer with other capabilities, and the session control – the session layer – is being broken out into three different CSCFs: the P-CSCF, the I-CSCF, and the S-CSCF. And you still have the session border controller, P-CSCF capabilities with the MRF.

      "The important thing here is to think of two different types of application server: one providing discrete end-to-end applications like telephony or video calling, for example, and the other providing enabling features that can be used by various applications servers – things like presence, group management, and instant messaging.”

      Specific challenges in making the transition include:

    • Dispersed and disparate data (in, for example, local database, HLR, presence, and AS) need to be integrated into a unique repository (the HSS), while still keeping data as close as possible to the IMS-AS.

    • Few 3GPP or TISPAN terminals are available today, even though IMS is starting to be deployed in the core.

    • IMS’s service-oriented architecture (similar to the Web Services model) highlights the need for convergence between telco networks and IT infrastructures.

    • Coexistence of vertical integrated applications, such as TISPAN emulated softswitch-based services, with new IMS session-based applications, is likely to be the rule for years to come.

      “Probably the biggest challenge is that today data is dispersed and disaggregated across the network,” says Mahony. “All of this will need to be integrated into a unique new repository called the HSS – developed in such a way that the data is still very accessible to the application servers.

      “One of the big things that will have to happen before we move to a fully horizontal IMS architecture in addition to the common session control is to disaggregate the HSS data and make that an available component and resource for any service and any device. And that is one of the key question marks: What is the business model for that? Who is going to host it? How is it going to be made available to the different service providers and the different application servers on the network?”

      IMS equipment platforms are going to be busy little beasts, as a quick view of Figure 4 indicates. Although the tasks and consequent platform requirements differ depending on whether the application, control plane, or data plane are involved, it’s obvious that one way of bringing down equipment costs is to increase volumes by developing common components for all three. This is where the PCI Industrial Computer Manufacturers Group (PICMG)'s Advanced Telecom Computing Architecture (AdvancedTCA) platform specification comes in, as it covers all three areas.

      ATCA is currently specified by the PICMG 3.X series of specifications. It is targeted at NGN carrier-grade communications equipment and incorporates high-speed interconnect technologies, next-generation processors, and improved reliability, manageability, and serviceability.

      Generic requirements for application servers include:

      Carrier-grade server platform

    • Interfaces and architecture designed to meet five-9s requirements of the TEM market

    • Both Intel Corp. (Nasdaq: INTC) architecture and PowerPC

    • Standards-based carrier-influenced platform

      Comprehensive and cost-effective platform architecture

    • Common platform infrastructure has been defined by PICMG

    • Linear scaleability of processing density

    • Processing power can be added in accordance with subscriber growth

    • Low starting price point and no price penalty for fully loaded box

    • Secure IP networking access to server clusters

    • CGL functions with application validation as well

    • Compliance or compatibility with enterprise, billing, and database applications

      Performance dimensions of an application server

    • Busy-hour call attempts

    • Subscribers per node

    • Sessions/streams per link

    • Number of links

    • Storage capacity

    • Processors per slot

      “Given the generic requirements we see coming out of the marketplace in terms of server and platform requirements, carrier-grade platform gets mentioned quite a bit,” says Eric Gregory, senior product marketing manager at Radisys Corp. (Nasdaq: RSYS). “That’s being addressed as part of the PICMG specifications: How do we do redundancy across blades? How do we do it within the shelf? How do we do it across shelves? That’s a very important aspect within an application server.”

      He points out that cost-effective scaleability is potentially very important, as many applications are likely to start out in a small way – service providers are likely to throw off a lot of ideas and see what sticks – but some of these could prove winners and take off very quickly. ATCA is well suited to support this kind of rapid scaling economically – for example, through slotting in faster processors.

      Internal Interfaces

      The ATCA PICMG 3.x specifications create openness within the hardware platform itself. The red lines in Figure 5 are the links between the different layers in the ATCA architecture. The Intelligent Platform Management Interface (IPMI) provides some links into the hardware platform itself – such as for shelf management, blade management, and carrier-grade operating systems (typically Linux). Above that, the Hardware Platform Interface (HPI) allows high-availability and system management. Each of the red lines provides hooks to the layers above and below.

      Finally, the Application Interface Specification (AIS) allows the high-level application software to provide hooks into the lower layers. Although there will be some remaining APIs to the payload specific to each blade, the Service Availability Forum (SAF) – which is developing high-availability and management software interface specifications – is doing a good job to standardize the interfaces between layers, according to Gregory.

      Server Architecture & Configuration

      Figure 6 demonstrates the basic modular approach to application server architecture made possible by the specification, where dedicated blades perform specific applications and tasks.

      “Some of these are quite generic, some are quite specific,” says Gregory. “Everything is going to hook into a common switching backplane. Most of the market is driving towards some sort of GigE switching backplane – at the moment we are really driving towards 10 GigE switching backplane to drive some of the higher-throughput applications.”

      He points out that IMS is big on security via IPSec and SSL, and in a real mixed environment will involve a lot of SS7 and SIGTRAN signaling, and also things like Diameter as well as SIP and STP signaling, so it makes sense to have options for dedicated security and signaling gateways in the reference architecture.

      The ATCA platform thus has considerable flexibility in terms of the different types of blade that can be slotted into a single shelf. Figure 7 shows a couple of examples.The top shelf shows an application server for Fibre Channel storage, so it will have several blades dedicated to disk storage, but also blades for signaling for Diameter or SIP switching. The bottom shelf, in contrast, shows an applications server with deep packet inspection – say, either for a session border controller or flow-based charging. Now there are a couple of blades doing packet inspection, and the disk storage is down to a single blade. So overall the platform has a lot of flexibility through slotting in specific blades for use with specific applications.

      ATCA’s flexibility extends also into mixing different applications and IMS functions within a shelf. For example, a single shelf could contain a group-list management server and presence application, comprising, say, a couple of storage blades and a computing blade, and also a CSCF, comprising storage, computing and signaling blades – and also blades for switching, IPSec acceleration, input/output, and so on.

      Packaged Products

      Total flexibility of the kind ATCA promises is one thing – early, practical IMS product deployments are possibly a little different. It’s more than likely that vendors will continue for some time the time-honored practice of producing platform packages for particular purposes.

      “We have already seen stratification of the different vendors in terms of focus,” says NetCentrex’s Mahony. “Clearly, the larger vendors are going to focus on the session control, the CSCF, and make sure that those all work well together. Other vendors, including NetCentrex, will focus on applications servers.

      "Even within that there is some bifurcation. Applications servers with integration to the applications themselves and with the application and service logic – I think this is the initial focus for the next couple of years. The ideal IMS deployment will eventually include the application server and then applications, as well as enabling features like presence and group management and chat, separated but also interworking seamlessly together. So it may take a couple of years before you see that separation, and in the interim, carriers are going to want to know that the application works well.”

      Similarly, Carl Rijsbrack, VP marketing and communications in the Fixed Solutions Division of Alcatel (NYSE: ALA; Paris: CGEP:PA), sees the need for combined IMS/SIP servers. “I think this is definitely a very important role. If we define converged IMS/SIP application servers as application servers able to handle hybrid environments – which means gluing together the traditional and new worlds – I believe this is a big evolutionary step that is going to be taken.”

      Simple session control and telephony applications are evolving to rich, multimedia, real-time, interactive sessions where capabilities such as presence will play an important role. The general idea of IMS at the highest level is to support this transition, and the method chosen is the trusty standby of functional layering. Figure 8 shows the three layers used in IMS: Application/Service, Switching/Control, and Connectivity/Transport.

      For applications and applications servers, the key points are that IMS supports convergence of applications and applications subsystems to create new kinds of multimedia services. And it also supports the provision of applications across different access networks, especially the convergence of wireline and wireless. It does this by separating the application and service layer from the switching and control layer, which is in turn separated from the connectivity and transport layer.

      An attractive characteristic of the development of IMS by the 3rd Generation Partnership Project (3GPP) is that it was built on existing frameworks, protocols, and standards – essentially IP and particularly SIP, both widely used in non-IMS settings. This has helped to embed IMS into the European Telecommunications Standards Institute (ETSI) TISPAN architectural work on converged NGNs.

      IMS & TISPAN – and Others

      IMS was originally defined by the 3GPP, but – because it’s a layered architecture that is access-agnostic – it’s since moved beyond 3GPP and is now included in the 3rd Generation Partnership Project 2 (3GPP2) specifications for CDMA mobile, in the PacketCable specifications for cable networks from CableLabs , and in ETSI TISPAN.

      TISPAN (Telecommunications and Internet converged Services and Protocols for Advanced Networking) is particularly important as it’s essentially a simplification and extension of IMS for use over fixed NGNs. Backwards compatibility is a must in this environment because of the massive base of legacy networks, so TISPAN uses MGCP at the edge and SIP in the core network, and thus allows carriers to get the benefits of IMS in their existing fixed networks. For example, TISPAN allows PBX interconnect through support for legacy H.323 – which is also a very important protocol for the huge base of MGCP-stimulus phones and devices.

      The ETSI TISPAN working group started to work on its NGN architecture in December 2003, and published its Release 1 architecture – based on 3GPP IMS Release 7 – at the end of 2005.Overall, IMS is getting a huge amount of attention across all the major network types, and its approach to applications and application servers looks set to become correspondingly influential in all areas of telecom service supply.

      IMS Applications

      Obvious IMS applications include:

      • Voice over IP

      • Audio/Web/videoconferencing

      • Push-to-talk, push-to-view, push-to-video

      • Rich media calls combining video and data

      • Multiparty gaming

      • Mobile IP Centrex

      • Mobile VPNs

      • Presence

      • Group chat

      • Multimedia advertising

      • Instant messaging

      • Unified messaging

      • Personal information services, calendars, and alerts

      • Video streaming

      • Interactive voice response

      But the hope is that this is just a starter list, because IMS will encourage service providers and telcos to faster and easier development of new, differentiated applications to reduce churn and increase ARPU. For example, they will be able to extend the capabilities of existing applications and introduce complex and dynamic service combinations, such as mid-call multimedia and combined TDM/IP services, in the same session.

      Finally, there is a lurking paradigm shift: IMS in principle allows service and application development and provisioning to be distributed in very much the same way that software and Web-based businesses are today. The hope is that a large, independent community of service and application developers will arise to power telecom innovation.

      Types of Application Server

      There are different types of application server defined within IMS and TISPAN, as illustrated in Figure 9.

      SIP application servers self evidently handle pure SIP-based applications, such as the familiar presence and instant messaging. Inside a SIP application server there can be different specific application servers directed via a function called the Service Capability Interaction Manager (SCIM). The SCIM is essentially a shortcut and orchestration capability, which allows interactions between the internal SIP application servers without having to descend directly to the CSCF to implement service sequences.

      Open Service Architecture (OSA) application servers handle non-SIP-based applications, providing the gateway and the bridging between, for example, Parlay-enabled applications.

      Also the IP Multimedia Service Switching Function (IM-SSF) interfaces with Customized Applications for Mobile networks Enhanced Logic (CAMEL) application servers and IN SCPs via CAP and INAP, respectively, to provide convergence with the mobile network – and the typical services are associated with SS7/INAP in the legacy fixed environment.

      What Application Servers Do

      Essentially, there are four aspects or roles for an IMS/TISPAN application server (AS):

      • An AS can provide an end-user service that includes communication service logic and client software.

      • An AS includes a software development kit (SDK) to allow service and content providers and developers to develop new services easily.

      • An AS can be a service enabler that can be called and shared by many end-user services.

      • An AS can interact with other ASs to generate new composite services via a Service Orchestration Framework.

      Openness is a key word here. Each of these four aspects or roles has to be fully open, because IMS is about creating an open application framework and environment. This environment will comprise multiple ASs – both for pure IMS applications and hybrid applications involving the traditional telecom and the IMS domain – and will be supported by a large community of third-party application developers. The latter is going to need the creation, validation, and deployment of a real ecosystem from a community of hundreds of partners and developers for network- and client-side applications.

      Further, it is obviously crucial that the application server interwork fully with existing BSS and OSS – it is not just a matter of dishing out services to the network.



Read more about:

AsiaEurope
Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like