PTT + IMS = PTM - Towards Community/Presence-based IMS Multimedia Services

Transcription

1 PTT + IMS = PTM - Towards Community/Presence-based IMS Multimedia Services Niklas Blum Fraunhofer Institute FOKUS Next Generation Network Integration Kaiserin-Augusta-Allee 31, Berlin, Germany niklas.blum@fokus.fraunhofer.de Thomas Magedanz Technical University Berlin Fraunhofer FOKUS thomas.magedanz@fokus.fraunhofer.de Abstract The specification of the IP Multimedia Subsystem as a service delivery architecture for Next Generation Networks and the introduction of Push-To-Talk (PTT) as an IMSbased service moves VoIP applications for mobile devices already to the market. PTT has gained a strong following in the US market and is on the verge of spreading globally. The Open Mobile Alliance (OMA) currently specifies PTT as an IMS-based service to assure interoperability between different operator domains. Most PTT solution vendors think already about extending PTT with other media types then voice, like video communication, file transfer or service subscription for content push services. Thus, Push- To-MultiMedia (PTM) does not seem to be that far away from market and is well suited as an enabler to provide IMS applications with advanced multimedia communication functionalities. The department for Next Generation Network Integration (NGNI) at Fraunhofer Institute FOKUS has created a PTM application that utilises the IMS architecture. This paper reports about a concept of integrating this PTT/PTM functionality in community-based applications to enable already existing groups and communities with new communication features. 1. Introduction The IP Multimedia Subsystem (IMS) is defined by 3GPP in [1] and represents the reference service delivery platform architecture for the provisioning of IP multimedia services within an emerging mobile all-ip network environment. It offers the convergence of the circuit switched telephony network and the packet switched Internet technology by defining interfaces and gateways to these bearer technologies. This means that mobile services and applications could be accessed ideally from different end systems, different access networks in a customised way. In this regard the notion of open service delivery platforms becomes of key importance. As a first example of an IMS application that will get to the market, the companies Comneon, Motorola, Nokia and Siemens specified a PTT service architecture called Push to Talk over Cellular (PoC PoC and PTT will be treated as synonymous in this document)[7]. The OMA currently specifies PoC as an IMS service using IMS inter-network interfaces to assure interoperability to other PoC networks, which will lead to rapid deployment of IMS technology at the telecommunication companies and operators. The competence center for Next Generation Network Infrastructure (NGNI) at Fraunhofer FOKUS has implemented a Push-To-Multimedia service featuring currently voice and video using the high-level Application Programming Interface of the Parlay Group [21] and the Java APIs for Integrated Networks (JAIN) [12]. The key aim of such APIs is to allow developers to create services using highlevel methods that are independent of the underlying network technology. This paper is organised as follows: Section 2 gives a brief overview of the IMS functionality with focus on application server and introduces the development of the PoC specification towards an IMS application. Section 3 describes our concept of an extension of PTT towards PTM. Section 4 provides an overview of the possible integration of PTM into community-based services. The paper is ended with concluding remarks in Section 5. 2 Related Standards Overview 2.1 The IP Multimedia Subsystem The IP Multimedia Subsystem (IMS) defines as part of the 3GPP Release 5 specifications an overlay architecture on

2 top of the 3GPP Packet Switched (PS) Core Network for the provisioning of real time multi-media services. It is based on IETF protocols like the Session Initiation Protocol (SIP) for session control and Diameter for Authentication, Authorisation and Accounting (AAA) and charging purposes. The basic IMS architecture is depicted in figure 2.1: Figure 1. Basic IMS architecture Due to the fact that the IMS overlay architecture is widely abstracted from the air interfaces, the IMS can be used for any mobile access network technology as well as for fixed line access technology as currently promoted by ETSI TISPAN within the Next Generation Network (NGN) reference architecture definition [22]. There are four additional key functionalities that mark the IMS as the future technology in a comprehensive service and application oriented network. 1) The IMS provides easy and efficient ways to integrate different services, even from third parties. Interactions between different value added services are anticipated. 2) The IMS enables the seamless integration of legacy services and is designed for consistent interactions with circuit switched domains. 3) The IMS supports for a mechanism to negotiate Quality of Service (QoS). Within a session, it is possible to request for QoS for certain Packet Data Protocol (PDP)-Contexts on the critical 3G air interface using a Policy Decision Function and the Common Open Policy Server protocol (COPS) [3]. 4) The IMS provides appropriate charging mechanisms for online and offline charging. Thus you can realise different business models and charge for specific events using an appropriate scheme. The particular techniques and methodologies that are required to gain the advantages of these key functionalities are not completely new, but the IMS provides the first major integration and the interaction of all key functionalities [15]. The Serving Call Session Control Function (S-CSCF) acts as a registrar for IMS users and is the central switch of the IMS. The Home Subscriber System (HSS) stores all the user and service related data. It is specified by 3GPP that the currently existing Home Location Register (HLR) is part of the HSS. The Media Resource Function (MRF) takes care of the media stream from and to the users connecting to the IMS. 3GGP specifies three different types of Application Servers: SIP Application Server OSA/Parlay Gateway CAMEL Application Server that is connect via an IP Multimedia Service Switching Function (IM-SSF) The Application Server (AS) is the service relevant part in the IMS. How the multimedia applications are programmed is out of 3GPP s scope. The SIP AS is supporting well defined signalling and administration interfaces (ISC and Sh) and thus SIP and Diameter protocols. This enables developers to use several programming paradigm within an AS, such as legacy Intelligent Network servers (i.e. CAMEL Support Environments), OSA/Parlay servers/gateways, or any proven VoIP SIP programming paradigm, like SIP Servlets [14], call programming language (CPL) and Common Gateway Interface (CGI) scripts, etc. IMS ASs are triggered by SIP messages that are routed by the S-CSCF according to message filters that are part of the initial Filter Criterias (ifc). These ifcs are downloaded by the S-CSCF on registration of a user from the user profile on the HSS using the sh-interface and the Diameter Base protocol [6]. The AS itself comprises local filter rules to decide which of the applications deployed on the server should be selected for the handling of the session. During execution of service logic it is also possible for the SIP AS to communicate with the HSS to get additional information about a subscriber or to be notified about changes in the profile of the subscriber. In the long run IMS is supposed to replace the service provisioning for the circuit-switched domain with packetswitched technology. 2.2 OSA/Parlay Application Server The aims of OSA/Parlay are to enable IT applications to request services provided by an operator s core network, so that IT and telecom application developers do not rely on network details and proprietary interfaces. This separation of the applications from the core network allows the

3 network operators to manage and control core network interfaces independently and to provide an open set of interfaces for third party applications [21]. As shown in figure 2, OSA/Parlay application provisioning exists always of two components: shows the components of a PTT service inside the IMS as specified by the OMA [16]. The following subsections will give a brief overview of the functionality of the most important entities for this paper. 1) An OSA/Parlay Gateway and 2) OSA/Parlay applications. The first one provides access to the underlying network capabilities, the latter one can be hosted on application servers that access the gateway through middle-ware technology. Figure 3. Components and Interfaces of PTT service in IMS as proposed by OMA SIP/IP Core Figure 2. OSA/Parlay API Parlay defines functional interfaces which are abstracting form concrete protocols and network technologies. The application implements only the Parlay API and usually no specific protocols. Therefore the applications can be considered as network independent. Each of the parts of the gateways is a specified interface. Push-To-MultiMedia at Fraunhofer FOKUS utilises the interfaces for Multi Party Call Control (MPCC) and User Interaction (UI). These interfaces were specified to connect several parties with each other and to interact with them. Each connection to a party is a so called call leg on which certain methods can be called through the OSA/Parlay API to create or manipulate the physical connection. 2.3 Push-To-Talk Push to Talk introduces a direct one-to-one and one-tomany voice communication service in cellular and wireless networks. Generally, the PTT solution is based on half duplex VoIP technology of the 2nd generation GSM/GPRS network. Ideally PoC will also be an integral part of the service offering of the IMS. The signalling is done via SIP [20]. Nevertheless, currently the PoC architecture is not fully compliant to the 3GPP IMS specification and can be considered as a first test for an IMS application. Figure 4 The SIP/IP Core provides basic IMS routing functionalities and includes the P-CSCF, I-CSCF, S-CSCF and HSS. It performs signalling operations for authentication, authorisation, call session control and maintains the session control functions for the endpoints. The P-CSCF is the first contact point within the IMS from UE perspective. It behaves like a proxy accepting requests and services them internally or forwards them to a S-CSCF [1]. The I-CSCF is the entry point for SIP messages to and from another operator s IMS. Generally in OMA PoC th SIP/IP Core offers the functionalities described in section PoC XML Document Management Server (XDMS) PTT users connect to an Aggregation Proxy to manage groups, contact lists and access lists using XCAP over HTTP. The Aggregation Proxy functions as a single entry point to the OMA XDMS functionality and forwards PoC related requests to the PoC XDMS. A contact list is a kind of address book as known from most Instant Messaging (IM) clients that may be used by PTT users to establish an instant talk session with other PTT users or PTT groups. Contact list management includes operations to allow the User Equipment (UE) to store and retrieve the contact lists located in the PoC XDMS. The end users defines the PTT groups and selects a group from the list to initiate a group talk session. The PTT server is accessing the PoC XDMS to retrieve information about participants of an invited group. Figure 4 depicts the XDMS architecture as defined by OMA [17]:

4 aggregates the presence information of the subscribed presentities into one document and authorises presence watchers by black and white lists stored in the presence XDMS. The Resource List Server is an optimisation for the presence functionality. It handles subscriptions to group lists by subscribing to each entry in the list separately. As a result it aggregates notifications for different list entries into one document and controls the rate of notifications where applicable. Therefore it optimises the usage of signalling traffic by reducing the amount of messages. Figure 4. Components and Interfaces of XDM service as proposed by OMA OMA uses the XDMS architecture as an enabler for PoC to provide the XML document management functionality to PTT users PoC / PTT Server The PoC Server contains the logic as well as the MRF of the PTT service. It performs as an end-point for SIP signalling as well as for RTP / RTCP signalling, it provides SIP session handling and also policy control for access to groups, as well as group session handling, access control and a talk burst control functionality. It is also responsible for charging reports and the media distribution Standardisation PoC has initially been specified as PoC Release 1.0 in 2003 by an industry consortium known as the MENSA consortium (Motorola, Ericsson, Nokia, Siemens and AT&T Wireless). This release did not include a presence server and no functionality for a Network-to-Network Interface (NNI). Nevertheless the user plane specification was already quite similar to the current OMA candidate release. MENSA Release 1 was shortly followed by Release 2, Ericsson and AT&T Wireless dropped out of the consortium and were replaced by Comneon and Motorola. A presence server and an interfaces between the Presence Server and a Group and List Management Server (GLMS) were specified, that was succeeded by the OMA XDMS and Presence SIMPLE architecture described above. Added was also an interface to remote PoC networks. During this time, the specification process was already handed over to the OMA, so release 2.0 never came into real life, because the proposed functionality will be included in OMA Release Presence Server A presence server has been integrated to manage presence information that is uploaded by the presence User Agent (UA) and is responsible for combining the presence-related information for a certain presentity from the information it receives from multiple sources into a single presence document. OMA makes use of its Presence SIMPLE Architecture for PoC [18] which is shown in figure 5. Since presence information is stored and transfered in XML, the XDM architecture also serves as an enabler for the presence functionality. The Presence SIMPLE architecture consists of three main components: 1) XML Document Management Server (XDMS) 2) Presence Server (PS) 3) Resource List Server (RLS) The Presence Server is the main component of the Presence SIMPLE architecture. It handles the publications and subscriptions and generates notifications when necessary. It Figure 5. Components and Interfaces of Presence SIMPLE architecture as proposed by OMA 3 From Push-To-Talk to Push-To- MultiMedia as a service enabler Push-To-Talk is an IMS-based service offering the semiduplex way of communication known by walkie-talkies to

5 hand-phone users. Push-To-MultiMedia [4] is our extension of PTT for multiple media types, like video, audio and instant messaging. Thus, Push-To-MultiMedia is similar to PoC, the service design splits apart the PoC function of the OMA specification into an IMS Application Server and a MRF according to the 3GPP IMS architecture [1]. The AS is taking part of the service logic, different MRFs perform the media handling. The media processing is fully independent of the SIP signalling, but is also controlled by the OSA/Parlay application. It sets bearer service type parameters using the Parlay interfaces for Multi-Party Call Control (MPCC) [8], which results in a generation of different parameters of the Session Description Protocol (SDP) [13] for different service requests at the OSA/Parlay gateway that maps the Parlay API to SIP and SDP. To control the media processing at the MRF, the OSA/Parlay gateway also translates the Parlay API to the Media Server Control Mark-Up Language (MSCML) [5]. The MSCML part is placed inside the SIP bodies of SIP INVITE and INFO messages that are sent from the AS to the MS. Generally several types of media attachment/interaction and, with rising bandwidth, the combination of them are possible: Instant messaging VoIP / Video File transfer Gaming SIP in combination with SDP allow a media independent creation of services, that are only limited by the bandwidth of the network and the capabilities of the end devices. Therefore Push-To-MultiMedia can be considered as the logical evolvement of PTT for NGNs. 3.1 Implementation of a PTM prototype This section describes our implementation of a PTM prototype at the IMS Fraunhofer FOKUS IMS FOKUS The FOKUS Open IMS Playground is deployed as an open technology test field with the target to prototype and validate existing and emerging IMS standards and to extend the IMS appropriately to be used on top of new access networks as well as to provide new seamless multimedia applications. All major IMS core components, i.e., x-cscf, HSS, Media Gateway (MG), MRF, Application Servers, Application Server Simulators, service creation toolkits, and demo applications are integrated into one single environment and can be used and extended for R&D activities by academic and industrial partners. All these components can be used locally on top of all available access technologies or can be used over IP tunnels remotely. Users of the Open IMS Playground can test their components performing interoperability tests. The SIP Express Router (SER), that has also been developed at FOKUS can be used as a reference implementation and to proof interoperability with other SIP components. The conformance of the SIP protocol to the standard can be tested by the usage of SIP conformance test suite. Yet, one focal point of the IMS Playground is put on the Application Server side. A variety of platforms enable rapid development of innovative services. The different platform options, each with their strengths and weaknesses, can be selected and used according to the customers needs Push-To-MultiMedia Architecture Push-To-MultiMedia was realised within the IMS Playground at FOKUS using an OSA/Parlay gateway implementing the Parlay interfaces for Multi-Party Call Control and User Interaction (UI) [9] that were mapped to SIP, SDP and MSCML. Figure 6 shows the basic architecture, which consists of the following distributed components: PTM Application Server (Parlay application and OSA/Parlay gateway) Media Server Presence Server GLMS It was important to us to be compatible to the proposed specifications of 3GPP and the OMA, but also to bring PTM forward to a real distributed environment of the IMS. OMA PoC proposes the integration of the Media Resource Function and application logic, which contradicts to the IMS architecture of 3GPP and complicates the integration of different media types. Instant Messaging, VoIP and VoIP with video extension is already possible with the current implementation. The media session depends on the capabilities of the client. The type of media is negotiated with the help of Session Description Protocol. Not yet implemented is an extension for file transfer and gaming, also because of the lack of standards for gaming in combination with SIP signalling. Most gaming vendors use proprietary signalling, integrated into their gaming engine. Nevertheless SIP could be easily used to establish the session between gaming partners.

6 Figure 6 provides an overview of the architecture of PTM at the IMS FOKUS [15]. is done using SIP. There are several methods specified, like floor request, floor granted, floor taken. Figure 6. Push-To-MultiMedia Architecture Future releases could actually leave out the limitation of semi-duplex media signalling and a resulting complex floor control mechanism, to extend the service to full conferencing. The idea of a buddy-list of friends to connect to for PTTsessions could be brought forward to a list of subscribed services that can push content to the user s end device Functionality The following figure 7 shows a signalling diagram for the session initiation of a PTM session. Interaction between the application and IMS entities like CSCFs and HSS are left out to make the diagram more concise. There is always an initiating client that is inviting a group or selected users to a Push-To-MultiMedia session. This client is sending its initial SIP INVITE including its SDP to the IMS Core. The S-CSCF is routing the SIP INVITE message to the corresponding AS using the information provided by the downloaded ifc for the initiating user. Since the Push-To-MultiMedia AS consists of the above described components, the Parlay gateway is receiving the message and notifying the Parlay application of the request. The OSA application then starts notifying the server-side component to send out SIP INVITEs to the session members. After receiving the SIP 200 OK messages from the other clients, the application is notifying all the other clients with SIP NOTIFY that the clients acknowledged on the PTM session. In the next step, the application is initiating an audio/video conference session at the Media Server and redirecting the clients to the Media Server, where the media processing is done. Currently, the floor control mechanism Figure 7. Signalling diagram of the initiation of a PTM session between two users Especially interesting is the MSCML part that can be embedded into SIP messages as described above and allows an external application to fully control media sessions and the in- and output of each attached leg. The first shown MSCML message initiates a full mixed conference session at the Media Server. The semi-duplex characteristic of PTT and PTM is assured by muting all the legs of the session participants that have received a Floor Taken talk burst control message. Using such a distributed approach, the media capabilities do not rely anymore on a dedicated PoC Server, but on the capabilities of the handset and the Media Server(s). The PTT Parlay application needs to establish call legs to finally invoke SIP transactions at the server side by calling methods like eventreportreq() to set a server side filter or routereq() to trigger a SIP INVITE message. This mechanism is known from classic telephony applications, but unknown to SIP. As illustrated in figure 8, there is no direct mapping to the low level protocol. The proposed mapping of the Parlay API to SIP [2] was extended by PTM specific modifications to allow functionality for talk burst control, since no mapping for SIP INFO and NOTIFY has been specified so far. Figure 8 depicts the mapping from Parlay to SIP for Push-To-MultiMedia.

7 trols the enablers. Figure 9 depicts the OMA Service Environment architecture: Figure 8. Parlay SIP mapping 4 Community-based Services on top of IMS and PTM This section describes our concept of how communitybased services can be enabled by the IMS infrastructure and PTM. Service developers for next generation mobile applications like group-ware solutions, mobile games and especially community-based services will want to make use of the advanced multimedia communication functionalities offered by IMS-based applications. But core communication functionality like voice- and video call control will reside at the operator s domain for security reasons as well as a well-defined integration of the services into the operator s charging and provisioning platforms. Most application developers will also not have the capability and resources to economically develop such complex communication features into their community-based services. Therefore an architecture needs to be introduced that enables third party applications to offer their communication functionalities to the users without the need for the application developer to implement the communication functionality into their applications themselves. An approach to such a functionality has been developed by the OMA which is commonly known as OMA Service Environment (OSE) [19]. Besides the Enabler Implementations, the key functions are a Policy Enforcer, that provides a policy-based management mechanism to protect the underlying Service Provider s resources from unauthorised requests and to manage the use of these requests through appropriate charging, logging and enforcement of the user s privacy or preferences. The Service Provider Execution Environment, that encompasses various functions such as process monitoring, software life cycle management, system support, operation, management and administration con- Figure 9. OMA Service Environment (OSE) Following the OSE approach Fraunhofer Institute FOKUS has created a concept for enabling applications with the Push-To-MultiMedia functionality, as depicted in figure 10: Figure 10. Enabling 3rd party communitybased application with PTM functionality The Push-To-MultiMedia application uses Parlay and ParlayX as binding to SIP and the ISC-interface of the IMS.

8 On top of the PTM application FOKUS creates simple to use Web Services API that can be utilised to instantiate a Push-To-MultiMedia session from a 3rd party application. During the on-going session, users can be added or removed through usage of the API. The session can be terminated by the application or by the involved terminals. Network service features like presence and group list management can be access directly through the usage of the ParlayX service interfaces for Presence [10] and Address List Management [11]. The call control functionality is realised by using the OSA/Parlay Multi-Party Call Control API as depicted in figure 8 and the OSA/Parlay API for User Interaction. But the community-based applications on top of the OMA Service Environment have also access to circuitswitched legacy services offered by an IN platform. Thus this approach not only wants to make use of IMS functionalities but also includes the already existent network capabilities of an operator s network. 5 Conclusion Currently operators around the globe are purchasing IMS architectures for their core network which enables them to offer convergent services to their customers based on IP technology. But who will these customers be, that will make use of the new advanced multimedia features? These users tend to be concentrated in the early-adopter mobile phone countries like Finland, Italy, Singapore or Japan and they easily use Instant Messaging, play networked video games, actively surf the fixed Internet, use , and may well be involved in blogging. But these are ancillary connection methods. The personal and primary connection tool for them is the mobile phone. Fraunhofer Institut FOKUS has implemented a Push-To- MultiMedia application that is described in this paper. It enables users with different communication channels. It was also described how these communication channels can be made available to community-based services using the IMS, OSA/Parlay and ParlayX. This approach opens-up the till now closed telecommunication world to the Internet developers that have no knowledge about the underlying network technologies and still keeps the operator s network secure by using the OSE policy enforcer. The OSA/Parlay interfaces offer a possibility to develop network independent open applications that can also be placed at 3rd party application hosts. Push-To-Talk is already in the market and seems to be a promising way to get closer to multimedia services for all-ip networks. Our extension illustrates that it is possible to extend the push functionality to a Push-To-MultiMedia architecture. Nevertheless, the proposed implementation of of an OMA Service Environment as shown in this paper is far more than a PTM enabler for community-based applications. As shown in figure 10, the service enabler do not only have access to the IMS, but also to circuit-switched networks to support legacy services. In this case the service enabler platform is also a Fixed-Mobile Convergence (FMC) platform. References [1] 3GPP TS23.228, IP Multimedia Subsystem (IMS); Stage 2 (Release 6) 3GPP (2004) [2] 3GPP TR , Mapping for Open Service Access; Part 4: Call Control Service Mapping; Subpart 4: Multiparty Call Control ISC (Release 5) 3GPP (2004) [3] 3GPP TS23.207, End-to-End Quality of Service (QoS) concept and architecture (Release 6) 3GPP (2005) [4] Blum, Magedanz Push-To-Multimedia as a Platform Enabler for NGN Services 11th European Wireless Conference 2005 (2005) [5] Burger et al. Media Server Control Markup Language (MSCML) and Protocol draft-vandyke-mscml-06 IETF (2005) [6] Calhoun et al. RFC 3588, Diameter Base Protocol IETF (2003) [7] Comneon Motorola Nokia Siemens Push-to-Talk over Cellular (PoC), PoC Release 2.0) Motorola (2004) [8] ETSI ES Application Programming Interface (API); Part 4: Call Control; Sub-part 3: Multi-Party Call Control SCF (Parlay 4) ETSI (2003) [9] ETSI ES Application Programming Interface (API); Part 5: User Interaction (Parlay 4) ETSI (2003) [10] ETSI ES Parlay X Web Services, Part 14: Presence ETSI (2005) [11] ETSI ES Parlay X Web Services, Part 13: Address List Management ETSI (2005) [12] Ferry et al. JSR22: JAIN SLEE API Specification Java Community Process (2004) [13] Handley et al. RFC 2327, SDP: Session Description Protocol IETF (1998) [14] Java Community Process JSR116: SIP Servlet API v. 1.0 Java Community Process (2003) [15] Knuettel et al. THE IMS FOKUS AN OPEN TESTBED FOR NEXT GENERATION NETWORK MULTIMEDIA SERVICES Testbeds and Research Infrastructures for the DEvelopment of NeTworks and COMmunities, TridentCom (2005) [16] OMA Push to talk over Cellular (PoC) - Candidate Version 1.0 OMA (2005) [17] OMA XML Document Management Architecture - Candidate Version 1.0 OMA (2005) [18] OMA Presence SIMPLE - Candidate Version 1.0 OMA (2005) [19] OMA OMA Service Environment OMA (2004) [20] Schulzrinne et al. RFC3261, SIP: Session Initiation Protocol IETF (2002) [21] The Parlay Group [22] TISPAN Telecommunications and Internet converged Services and Protocols for Advanced Networking ETSI (2004)