The IP multimedia domain: service architecture for the delivery of voice, data, and next generation multimedia applications

Transcription

1 Multimed Tools Appl (2006) 28: DOI /s The IP multimedia domain: service architecture for the delivery of voice, data, and next generation multimedia applications Vassilios Koukoulidis Mehul Shah 1 C Science + Business Media, Inc Abstract The IP Multimedia Subsystem (IMS) is defined by the 3 rd Generation Partnership Project (3GPP) as a new core network domain. IMS provides a service control platform that allows creation of new multimedia and multi-session applications utilizing wireless and wireline transport capabilities. In this paper we will cover the concepts and standards defining IMS and review the network architecture from a mobile perspective. We will see how IMS interacts with the Packet Switched Domain (e.g. Wireless LAN, GPRS, and UMTS networks), the Internet, and application services. Then we will examine the key IMS capabilities and show how they can be combined to create new mobile IP services. Finally, we present a software architecture, which is enabled by IMS and allows development of unique applications (with multimedia/multi-session functionality, single/multi-user, service to user). The software architecture is illustrated by an example of a prototype application. Keywords IMS. IP. SIP. Multimedia. UMTS. GPRS. GSM. WLAN. WiFi 1. Introduction Users highly desire services satisfying their need for information, entertainment, work, and community. These services are widely available today via the Internet. In addition to accessing a rich set of services, users need the capability to access such services everywhere. Wireless networking and recent efforts to merge fixed and mobile network services can provide the latter. Today, the Internet can be accessed via 2G or 3G networks, mainly through the packet-switched domain. There is however a few constraints in providing multimedia and V. Koukoulidis ( ) Siemens Communications Inc., Boca Raton, FL, USA [email protected] S. Shah T-Mobile USA Inc., Bellevue, WA, USA [email protected] 1 This work was done when the author was with Siemens Communications Inc., Boca Raton, FL

2 204 Multimed Tools Appl (2006) 28: multisession services that a user can actually enjoy. Next, we discuss these constraints and show how they can be circumvented via a standardized approach. Real-time multimedia services are the natural and inevitable enhancement of the current service landscape. Also, users require concurrent multi-session capabilities from their applications. Typically, these sessions have different requirements on end-to-end delay characteristics, throughput, and reliability (e.g. a user may need to attend an audio/video conference via his mobile device while keeping an eye on the presence information of the other attendees). In other words, such scenarios require sessions with various grades of Quality of Service (QoS) that should be established at session set-up and maintained throughout the life of the session (presently, the only QoS available to an Internet user is best effort). In this context, the network operator must modify user charging according to each session QoS. Users of mobile devices require applications that will not only utilize networks of various speeds and QoS, but also access their services via different transport technologies and using different devices. High-speed, mobile networks are not yet widespread; therefore applications must optimize the use of the network transfer capabilities. The IP Multimedia Subsystem (IMS) is a standards-based architecture that addresses all of the above requirements i.e. IMS makes it possible to provide integrated Internet-based, multimedia, multisession applications to mobile users, guarantee the QoS across different access network technologies, and allow operators to charge accordingly. In addition, IMS standardizes the service creation interfaces, which allow third-party vendors to develop new applications for operators and users. In this paper, we overview IMS and related protocols and standards. We briefly discuss IMS standardization process and bodies, and emphasize on SIP protocol the main control protocol for developing IMS services. Finally, we demonstrate, via an example, how new and innovative IP-based real-time/multimedia/multisession applications can be developed for IMS. Our preferred development model is client/server architecture using open architecture with smart clients. 2. Network architecture for multimedia/multisession services 2.1. IMS architecture IMS allows convergence of different transport networks by employing a standardized architecture independent of the access network technology, as shown in Figure 1. The idea of using a common device and single phone number across different access networks is currently under development or early deployment phases by the mobile industry. This concept is being addressed for both 2G and 3G networks and referred to as Unlicensed Mobile Access (UMA), Fixed-Mobile Convergence (FMC), or Voice Call Continuity (VCC). In this paper the terms FMC and VCC are used interchangeably. In its more advanced development stages, FMC will allow users to seamlessly roam or hand over calls between different access networks (e.g. 2G/3G and WiFi). UMA, FMC and service continuity between IMS and other domains is beyond the scope of this paper. In terms of OSI reference model, IMS is responsible for providing session layer control functionality as shown in Figure Standardization and protocols The main aim of the IP Multimedia subsystem is to provide value added IP services using existing cellular technologies such as GPRS, EDGE and UMTS. The IMS has used a number

3 Multimed Tools Appl (2006) 28: Fig. 1 IMS-based services are available to IP devices through any access path of protocols that were already defined for use in the Internet world and also necessitated the creation of a number of new protocols. Before we delve any deeper into the protocols that are used in the IMS it is important to introduce the standardization bodies that are responsible for the development of the IMS as an entity. We will then explain the collaboration between the different bodies that has resulted in the evolution of the IMS. Fig. 2 IMS layered view: Network components and functions per layer

4 206 Multimed Tools Appl (2006) 28: Standardization bodies Third Generation Partnership Project (3GPP) The European Telecommunications Standards Institute (ETSI) was responsible for the creation of the Global System for Mobile Communication (GSM) during the early 1990s. This body was also responsible for the standardization of the General Packet Radio Service (GPRS) which was the first step in the evolution of the GSM network towards a true third generation system. The 3GPP was created to develop a third generation telecommunication system based on the GSM specifications. The 3GPP is organized into a number of working groups, known as Technical Specifications Groups (TSG) whose work is overseen by the Project Co-ordination group (PCG). The output of the working groups takes the form of Technical specifications (TS) and Technical Reports (TR). The TSG approves these reports for use in a particular region of the world. All specifications are grouped by the 3GPP into Releases. The IMS was first introduced in 3GPP Release 5. All technical reports and specifications are available to the public via the 3GPP website at: Third Generation Partnership Project 2 (3GPP2) Since the 3GPP was created to chart the evolution of the cellular networks based on the GSM (European) specifications into a third generation system, a similar need was felt to create an organization which would do the same for the North American and Asian cellular networks based on ANSI standards. Thus, the 3GPP2 was born. The organization structure of the 3GPP2 closely resembles that of the 3GPP, with the technical work being done by Technical Specifications groups whose work is overseen by the Steering Committee (SC). The IMS according to the 3GPP2 was first introduced in Release A of the specifications. Technical Reports and specifications are available to the public via the 3GPP2 web site html/specs. It is important to note that both the 3GPP and the 3GPP2 have standardized different versions of the IMS. Although both versions of the IMS are pretty much similar, there do exist some significant differences [1]. Internet Engineering Task Force (IETF) The IETF is an organization of operators, vendors, network designers and researchers whose common goal is to work towards the evolution of the Internet architecture and protocols. There is no membership of the IETF and it is open to any interested individual. Most of the protocols that are in use today in the Internet were standardized by the IETF. The IETF working groups are grouped into areas, and managed by Area Directors, or ADs. The ADs are members of the Internet Engineering Steering Group (IESG). Providing architectural oversight is the Internet Architecture Board, (IAB) (Give reference). The technical work within the IETF is done by working groups. Each working group is given the responsibility of a particular task such as creating a new protocol. The documents created by the working groups are called Request for Comments (RFC). Individuals who are not part of any working groups can also formulate these RFCs. Open Mobile Alliance (OMA) OMA ( was formed in 2002 by the mobile industry with the objective is to specify mobile service enablers (e.g. digital rights management, and push

5 Multimed Tools Appl (2006) 28: to talk over cellular PoC) that will ensure service interoperability across different platforms, operators, and networks. OMA recognized that in order for service enablers to interoperate efficiently, they should be able to use a common set of basic service capabilities such as security, quality of service, charging, session management, etc. Since IMS can provide the interface to these basic capabilities, using IMS will make service architecture modular, and easier to specify and develop [2]. OMA as a body specifying applications and services (application layer) does not explicitly require the use of IMS (session layer) Collaboration between standardization bodies When the IMS standardization body needs a particular protocol to perform a specific task, it uses the Internet protocol for that particular task and makes it the protocol of choice for the IMS. In cases where the existing protocols do not fulfill the requirements of the IMS, an extension to the protocol is drafted or a totally new protocol is created by the IETF. Already, several protocol specifications and protocol extensions have been written by the IETF in the form of RFCs or Internet Drafts. The collaboration between the 3GPP and the IETF is explained in RFC 3113 [6] There is no formal co-operation between OMA and 3GPP, however, due to the benefits of using standards-based service interfaces to the network infrastructure (i.e. the interfaces provided by IMS), the co-operation between OMA and 3GPP is likely to increase Protocols The protocols that have been defined in the architecture of the IMS can be classified in three broad categories: a) Protocols used in the signaling or session control plane. b) Protocols used in the media plane. c) Authentication and security protocols Session control protocols The protocol chosen by the 3GPP for session control in the IMS is the Session Initiation Protocol (SIP) defined in RFC3261 [4]. The main use of SIP is to establish, modify and terminate multimedia sessions. SIP is independent of the media being transported and relies on other protocols for transport or QoS reservation. Figure 3 shows how SIP fits in the protocol stack of a typical IP-based network. The main entities that are present in a SIP network are the User Agent (UA), Registrar Servers, Proxy Servers and re-direct servers. The user agents initiate and receive SIP requests and generate the provisional and final responses. The registrar server is responsible for keeping track of the users location. The user agent usually sends a registration message to the registrar and the registrar stores the registration information in a location server for future use. A proxy server is nothing but a router that receives and forwards SIP requests and responses. Redirect servers receive SIP requests and then return alternate locations where the user may be available. In a SIP session, a request originates from a user agent, travels through one or more proxy or re-direct servers and terminates in another user agent. SIP is based on an HTTP like request/response transaction model. The requests and responses are grouped together into transactions. Each transaction consists of a request, one or more provisional responses and a final response. SIP messages use either the User

6 208 Multimed Tools Appl (2006) 28: Fig. 3 SIP stack and related protocols Datagram Protocol (UDP) or the Transmission Control Protocol (TCP) as the transport protocol. Usually UDP is preferred as it avoids the overhead associated with TCP connection setup and teardown. SIP is a text-based protocol so that it is easier to debug, extend and implement. The main methods of SIP are summarized below. For a complete description of these methods and the RFCs defining them the reader is referred to [3]. Basic SIP methods INVITE: To initiate a session (session description included in message body) Re-INVITE is used to change session state REGISTER To bind a permanent address to current location (i.e. to notify the SIP network server about a user agent s current contact information) This method may also convey user data ACK To confirm session establishment BYE To terminate a session CANCEL To cancel a pending INVITE OPTIONS To query a user agent about its capabilities and/or determine its status

7 Multimed Tools Appl (2006) 28: SIP Methods for Presence Management SUBSCRIBE To establish a subscription for notifications about a specific event (e.g. changes on presence information about another user). NOTIFY To convey information to a subscribing user regarding the status of an event. In addition to the above methods, there are several other methods such as REFER (to request another user agent to access a resource), MESSAGE (to transport instant messages), UPDATE (to modify the state of a pending session), INFO (to send call signaling information) and PRACK (to acknowledge receipt of reliably transported provisional responses, i.e. responses that are critical in determining the call state). SIP works in close conjunction with the Session Description Protocol (SDP) for initiating multimedia sessions. SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. The SDP consists of two parts: 1) Session level information and 2) Media level information. The session level information applies to the whole session while the media level information applies to the media stream. SIP works independent of the type of protocol used for the session description. Use of SIP in Session Establishment Session establishment generally consists of the following steps: 1) Session Initiation: This step includes the discovery of the user whatever the location and addressing the user by a globally unique SIP identifier, which is known as the SIP URI. 2) Delivery of Session Description: Once the user has been located, a description of the multimedia session is delivered to it. SIP itself is not aware of the type of media used in the session. The most common protocol used for delivery of the description is the Session Description Protocol (SDP). 3) Session Management: The delivery of the session description to the callee usually elicits a response from it in the form of an accept or reject. If the response is an accept, the session is said to have been established and vice versa. If a multimedia session is established, media streams can now be directly exchanged between the two endpoints. The most common protocols used for the transport of real-time data are the Real Time Protocol (RTP) and the Real time Streaming Protocol (RTSP), which will be explained in a later section of the paper. 4) Session Termination: Once data in a particular session has been exchanged, either party can request that the session be terminated. Session Initiation Example In the following, we illustrate how SIP is used for session establishment. Before any session can be initiated it is necessary for the endpoints (or user agents) to be registered in the IMS network. A SIP registration, depicted in Figure 4, is a way for the end point to make itself known to the network and also for it to advertise its current location where it can be reached. For example User A (UA) registers itself with the IMS network with its public user identity (sip:[email protected]) and makes it known to the network that it can be reached at sip:[email protected]. It is possible for the user to have multiple public user identities. Each public user identity that is being used has to be registered in the network.

8 210 Multimed Tools Appl (2006) 28: Fig. 4 SIP registration A special node in the network called the SIP Registrar receives the REGISTER message. The registrar binds the users SIP URI (or public user identity) with its contact information for future use. The registrar responds with a 200 OK to indicate that the registration transaction was successful. Assuming that two users (User A and User B) have registered themselves in the IMS network using the procedure explained above, a media session can be established between them refer to Figure 5. To initiate the SIP session, user A s (caller) SIP client creates an INVITE request for user B (callee) which is usually sent to the proxy server of the caller s domain (1). Upon reception of the INVITE request the proxy server tries to query the IP address of the server, which handles the domain of the destination user. Fig. 5 Session initiation

9 Multimed Tools Appl (2006) 28: A location server is used to determine the next hop server to which this request has to be sent. For simplicity we assume that the destination and the originating domain are the same so that the proxy server need not query the location server. The proxy server forwards this INVITE to the destination machine (2). This INVITE request contains an SDP payload that informs the callee of the particulars of the media session: codecs, port numbers and the type of media session (audio and/or video). The callee will either accept or reject the invitation for session initiation depending on whether it supports the session requirements or not. In our example the callee accepts the session invitation by sending back a 200 OK response to the caller via the proxy server ((3) and (4)). This response has the IP address and the SIP URI of the callee, so that the caller now can send an ACK directly back to the callee, bypassing the proxy server (5). This shows that the main purpose of the proxy is to facilitate the location and contact of the two end points. Once this is accomplished it then drops out of the signaling path. Once the two end points discover each other, media stream(s) can then be transferred peer-to-peer. The path taken by SIP signaling is completely independent of the path taken by the media traffic. This leads to the clear separation of the signaling and media planes. Session termination can be initiated by either of the two parties by sending a BYE (6) message Media plane protocols The IMS uses the Real Time Protocol (RTP) and the Real Time Control Protocol (RTCP) for media delivery. RTP defined in RFC3550 [8] transports real time media such as audio and video using UDP as the transport protocol. RTP is always used in combination with RTCP [8], which provides statistics and information about the media stream. Since the media packets are delivered over an IP network, there may be cases in which packets are delayed in their arrival at the receiver. If two IP packets are sent out consecutively, it may happen that the second IP packet may be received earlier than the first one due to delays and jitter in the IP network. To enable the receiver to play media at the desired pace, RTP timestamps are used in media packets. The receiver puts the media packets in a buffer in the order of their RTP timestamps and then starts playing the media. RTP packets also have sequence numbers associated with them. These sequence numbers are used to determine the packet loss in the network. If the network congestion results in more packets being lost, the sender and the receiver can switch to a different codec that can provide better quality of service. RTCP is always used in conjunction with RTP. It is used to provide quality of service statistics and information to perform inter-media synchronization. The QoS statistics are generated by using RTCP to report the number of RTP packets that have been sent and received by peer entities. Thus, packet loss can be calculated. Perhaps the most important use of RTCP is to perform the mapping between the RTP timestamps and a reference clock. Using this reference clock enables the receivers to perform media synchronization such as co-relating audio and video packets so that both are played back at the same instance. This is important in video conferencing applications Security and authentication protocols There are three interfaces (Cx, Dx and Sh) [1] in the IMS architecture that use authentication functions. In all these interfaces the authentication protocol used is DIAMETER [9]. DIAMETER is an improved version of an earlier authentication protocol called RADIUS [10]. DIAMETER is specified as consisting of a base protocol and other Diameter applications that use this base protocol. A Diameter application is one in which the basic functionality is customized to suit a particular functionality. Diameter is run over reliable transport

10 212 Multimed Tools Appl (2006) 28: Fig. 6 Silo v/s IMS approach for applications development protocols like Transmission Control Protocol (TCP) and Stream Control Transmission Protocol (SCTP). 3. IMS applications development The adoption of the IP multimedia subsystem will be driven by killer applications that can be personalized and present a seamless user experience across various types of services. It will not be uncommon for applications to combine services such as instant messaging, streaming video, audio, location based service, and presence into one package. Providing to users integrated applications is facilitated by a generic service platform, such as IMS (Figure 6). Developing mobile multimedia applications is quite different from developing applications for desktop devices where for the most part the same kind of platforms and operating systems are standardized or widely used. Compare this with the mobile domain where applications are expected to run on various hardware platforms (ARM, XScale), on different operating systems (Win CE, Symbian OS, Palm OS) and on devices that have different screen sizes and ways of human interaction (touch screen, joystick or soft keyboard). All this means that application developers have to think differently and change the approach that is used in designing such applications. We briefly describe some areas that will affect application development Application architecture Typical application architecture follows the client/server model, unless only peer-to-peer functionality is required. The server architecture is typically a container consisting of building blocks, which, when combined, allow development of distinct applications. The client is usually a smart client [5]. The overall system architecture is illustrated in Figure 7.

11 Multimed Tools Appl (2006) 28: Fig. 7 SIP client/application server architecture The SIP application server (A/S) is the service creation & execution platform within the IP Multimedia Subsystem (IMS) of the 3GPP (& 3GPP2) architecture and communicates with The Serving Call-Server Call-Function (S-CSCF) for call control functions via the standard IMS Service Creation (ISC) interface. The Home Subscriber Server (HSS) via the Sh interface in order to perform user registration functions. External applications. The SIP A/S in SIP and Voice over IP (VoIP) networks is analogous to J2EE/Web A/S in HTTP/Data networks. A SIP A/S could be implemented as a SIP servlet container consisting of Application Building Blocks (ABB), such as presence management, location management, messaging, or conferencing. External application servers can access these building blocks via well-defined APIs in order to combine multiple ABBs in unique applications. The SIP A/S also provides full access to SIP signaling. The availability of a plethora of smart handsets and handheld devices means that the applications that run on these devices have to be designed in such a way as to achieve portability and maximum flexibility. The most preferred way to design these applications is the layered approach in which the application architecture is split into three main layers: the UI layer, the application logic layer and the protocol layer as shown in Figure 8. The user interface is nothing but a visual representation of the user data that is stored in the application engine. It also gives the user the ability to enter information using the various data entry modes supported by the device. The application engine has all the necessary data and algorithms of the application and also provides means to store the data either in a transient or permanent format (file storage or memory card storage). The engine should be de-coupled from the UI layer and ideally should have no dependence on the UI layer itself. Information can be passed from the engine to the UI and back via published application programming

12 214 Multimed Tools Appl (2006) 28: Fig. 8 Smart client software layers interfaces (APIs). Also, some level of de-coupling is required between the engine and the protocol stack so that different protocol stack implementations from different vendors can be used with the same application engine. This type of layered application design facilitates code re-use, minimizes inter-dependency between functional components and ease of testing. The UI and engine can be developed and tested simultaneously thus reducing development time. This concept of separating the UI and the engine is certainly not new, but in light of the various devices that are proliferating the market and the need to develop application on ever-tighter deadlines, it assumes greater significance. The separation of the application logic from the UI logic means that by re-designing/recoding the UI parts of the application, it is possible to port the application from one device to another. An example of this would be an application designed to run on Symbian OS series 60 devices that after modifications to its UI logic can be ported to Symbian OS UIQ devices. This is true for applications that are written in a native language such as C++. To achieve true portability, it is recommended that applications be written in platform independent languages such as Java. However, Java suffers from performance issues that we will talk about in the next section Native versus Java applications The main advantage of using Java in application development is the cross-platform advantages that it provides. A single copy of the source code is required when porting application across different platforms. If the devices have different form factors, then the user interface may have to be adapted according to the capabilities of the device (screen size, user interaction and so on). However this can be achieved with minimal effort. The absence of pointers and the concept of garbage collection make it a very attractive language to program in. However, the main concern in Java applications has been performance. Since most mobile devices have processors that are constrained for speed, Java s performance issues do not allow for a good user experience. The primary advantage in developing native applications is performance. The ability of application developers to directly access the operating system using C/C++ gives them a powerful advantage in being able to access the capabilities of the OS without having to go through additional layers. This is most often required when accessing wireless communication protocols and access to telephony components. Also, since native languages have been around for a number of years as compared to Java, the development tools like Microsoft Visual Studio, embedded Visual C++ have been refined over the years and offer a solid development environment. Java development tools haven t been around as long and are not as mature.

13 Multimed Tools Appl (2006) 28: Fig. 9 Functional overview of movie location service 3.3. Example of converged multimedia application movie location service Application functionality In order for an application to attract and hold the interest of the user, it should combine a wide variety of components like presence, multiparty chat, location, scheduling, e-commerce, streaming video and dynamic content (to name a few) into a user-friendly user interface (UI). The UI plays a key role in such applications. Since, the display on most wireless devices is constrained, presenting the user with meaningful information and enabling him to seamlessly switch between one information source to the other play a very crucial role. In the following, we show a representative application highlighting the points discussed so far. The Movie Location Service (MLS) application is an example of a converged application, which is probably a glimpse of things to come in the rapidly expanding world of multimedia applications. The aim of MLS was to create a showcase application, which would highlight the capabilities of the IMS and at the same time give the developers a framework on which similar applications could be built. MLS provides the following services to the user (Figure 9): Movie info-entertainment content including video clips (streaming video) Users can browse movies by current showings, Top 10 box office, theater name, title, user location, and area. Users can request that a movie trailer or clip be streamed to the terminal. Location-based services Users can locate theaters by user location, movie title, area, and theater name. Messaging and Chat services A user can share movie content with a friend or group of friends via instant messaging and chat services.

14 216 Multimed Tools Appl (2006) 28: Fig. 10 Example service flow of movie location service Presence services A user can select friends on his buddy list and perform actions such as share a movie clip, invite to a movie, send an instant message, chat, and view calendar. Ticketing services A user can purchase tickets for movie events and can specify the form of payment, e.g., credit card or consolidated payment using his existing wireless bill. Calendaring services A user can schedule a movie event in his calendar and in his friends calendars. An example service flow of the MLS application is illustrated in Figure 10. The application software architecture is shown in Figure 11. The MLS service comprises of two tiers: MLS Application Server tier MLS Client tier The communication between the Application Server and the Client is based on IP-based protocols as follows: Messaging SIMPLE (MESSAGE SIP EXTENSION) Presence SIMPLE (SUBSCRIBE, NOTIFY and PUBLISH SIP EXTENSIONS) Streaming Video RTP and RTSP Calendar icalendar (HTML/HTTP) Movie Info-entertainment XML/SOAP/HTTP How these protocol interfaces are used to communicate to other IMS network elements and service-enabling platforms is defined within the 3GPP organization as follows:

15 Multimed Tools Appl (2006) 28: Fig. 11 Movie location service architecture S-CSCF - ISC Interface to Application Server HSS - Sh Interface to Application Server The mobile client communication to the Streaming Media Server to establish video sessions is based on standard protocols like RTP and RTSP. The client specifies a URL (provided by the Application Server) and directly communicates to the streaming server. The backbone protocol of the application is SIP and is used to deliver rich multimedia services. Without SIP many of the services provided by MLS would require multiple interfaces in the mobile terminal instead of service integration on the network side User interface Since many components are integrated into the MLS service, all of them must be available to the user in an easy to access manner. For example, when the user has selected a particular movie and wants to chat with his/her buddies about the movie, the movie information (description, reviews, preview link etc.), the presence status of the buddies (online, offline, unavailable, etc) and the chatting window must be available concurrently to the user. There are many ways to achieve this; one of them is shown in the screen shot in Figure 12. A more traditional desktop-like (tab switching) method could have been employed, however it requires that user switches between multiple tabs several times leading to a cumbersome user experience Application setup As with any application, MLS allows the user to modify his/her settings via a series of setup screens. The user has the option of modifying the access method (WLAN, GPRS),

16 218 Multimed Tools Appl (2006) 28: Fig. 12 Movie location service user interface (on-line screen instance) personal information (name, address, phone number), content preferences, network information (CSCF, HTTP server, Presence server, IM server addresses) and payment information (credit card information). The screen shots in Figures 13 and 14 illustrate the network and personal/content settings options Additional applications While we have discussed a specific example of a multimedia application that encompasses multiple services, there exists the possibility to create virtually an endless realm of applications. Examples of such applications that can be enabled by IMS include: Push to Talk over cellular (PoC) Enhanced Call Line Identification (ecli) Multimedia Conferencing Push Services Fig. 13 MLS network settings screenshots

17 Multimed Tools Appl (2006) 28: Fig. 14 MLS content settings and personal settings screenshots Personalized Video on Demand (PVoD) See What I See (SWIS) Picture Share Video Share Interactive gaming with simultaneous voice session The above examples serve to illustrate only a tiny fraction of the number of services that can be deployed using IMS. Using a number of building blocks it is possible to combine them in an exponential manner and create services that can be easily integrated using IMS. 4. Operator benefits As more and more users show a keen interest in data services, network operators need to upgrade their existing voice-centric networks to accommodate such users. The 2.5G networks of today (GPRS, EDGE) are a first step towards such a migration. However, this will not be enough, as these networks merely tend to act as access networks for content residing beyond the control of network operators. This leads to a situation where the operator can charge only for the amount of data traffic (bytes) that passes through his network without actually moving up the value chain and charging for the type of content that the user accesses. Thus, mobile network operators (MNO) may be relegated to be pure bit-pipes. IMS offers the operator a rapid service creation environment thereby allowing the MNO to build, own and control new IP-based mobile services and applications. IMS is also able to provide enhanced ranges of services like user-to-user, multi-user and server-to-user, each of which has the potential to generate new revenue streams for the operator. The use of standardized interfaces means that 3 rd party applications can also be easily integrated into the IMS framework allowing for a plethora of rich multimedia applications to reach the user in a short span of time. References 1. Gonzalo Camarillo and Miguel-Angel Garcia-Martin, The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds, John Wiley & Sons: Poikselka, M. et al., The IMS: IP Multimedia Concepts and Services in the Mobile Domain, Wiley: 2004

18 220 Multimed Tools Appl (2006) 28: Alan, B. and Johnston, SIP: Understanding the Session Initiation Protocol, Artech House: Rosenberg, J. et al. SIP: Session Initiation Protocol, RFC 3261, June Martyn Mallick, Mobile and Wireless Design Essential, Wiley: Rosenbrock, K. et al., 3GPP-IETF Standardization Collaboration, RFC3113, June Handley and M., Jacobson, V. SDP: Session Initiation Protocol, RFC2327, April Schulzrinne, H. et al., RTP: A Transport for Real Time Applications, RFC3550, July Calhoun, P. et al., Diameter Base Protocol, RFC3588, September Rigney, C., Willens, S., Rubens, A. and Simpson, W. Remote Authentication Dial In User Service, RFC2865, June 2000.