Push-to-Talk in IMS Mobile Environment

2009 Fifth International Conference on Networking and Services Push-To-Talk in IMS Mobile Environment Rui Santos Cruz∗ , Mário Serafim Nunes† , Guido Varatojo‡ , Luı́s Reis‡ ∗ IST/Zapp–Radiomóvel Telecomunicações, SA, Sintra, Portugal † IST/INESC–ID, Lisboa, Portugal ‡ IST–Instituto Superior Técnico, Lisboa, Portugal Email: [email protected], [email protected], [email protected], [email protected] Abstract—The IP Multimedia Subsystem (IMS), originally designed by 3GPP and later updated by 3GPP, 3GPP2 and TISPAN, presents itself as an architectural framework that allows the convergence of the Internet, wireless and wireline networks and a global platform for the delivery of IP multimedia applications in Next Generation Networks (NGN). One of the most used services to test IMS capabilities is PushTo-Talk (PTT). This service follows the IMS specifications and has motivated standardization work by the Open Mobile Alliance to assure interoperability between different operators. This paper describes a PTT over IMS solution designed with a Talk Burst Control Protocol based on SIP messages for call session control. The implementation was deployed and tested both with highbandwidth LAN and CDMA2000 wireless network, demonstrating that IMS is a powerful and flexible architecture allowing the quick and easy development of multimedia applications, like PTT, for convergent networks Index Terms—Push-To-Talk, Talk Burst Control Protocol, IMS, PTT. I. I NTRODUCTION In recent years the telecommunications industry has experienced dramatic changes. Competition between operators has become more intense, users have become more demanding every day and Internet usage continues growing in leaps and bounds. For these reasons operators need to keep rushing to create new services aiming to fulfill or exceed users expectations so they can win a competitive advantage over other operators. Users want attractive communications services at low costs and with the increasing usage of the Internet they want to access all its services from any device, anywhere. To answer these demands, the standards body 3rd Generation Partnership Project (3GPP), as part of the vision for evolving mobile networks beyond GSM, designed an architecture to deliver “Internet services” over Packet Radio Services. That architecture is the IP Multimedia Subsystem (IMS) [1], [2]. This vision was later updated by 3GPP together with 3GPP2 and ETSI’s TISPAN [3] to a harmonized IMS-centric core architecture, allowing the convergence and interworking of wireless and wireline networks to allow telecommunication operators to offer all internet services worldwide, with high levels of quality of service, different ways of charging and easier integration of the various services, regardless of the user’s access network. One of the most used services to test almost all IMS capabilities is Push-to-talk (PTT), expected to be one of the first services available on a large amount of operators, for its 978-0-7695-3586-9/09 $25.00 © 2009 IEEE DOI 10.1109/ICNS.2009.90 reduced requirements and its tolerance to delay and connection bandwidth. This work was part of an IMS demonstrator testbed to evaluate IMS capabilities. It consisted on the development of a PTT Application Server (AS) as well as a PTT Client, respecting as closely as possible the IMS principles established by the 3GPP/3GPP2 as well as the Open Mobile Alliance (OMA) recommendations on the Push-To-Talk Over Cellular (PoC) system definitions [4], but using a few modifications to apply concepts derived from research on IMS, namely from FOKUS [5]. The PTT client consists of an application with a graphic mode, developed with Java for desktop. Several tests were carried out with the PTT system, using both a highbandwidth LAN connection and a Code Division Multiple Access (CDMA2000) network. In this paper, Section 2 gives an overview of the IMS architecture, the PTT service and respective key requirements. Section 3 and Section 4 describe the implementation of the IMS core functions and the proposed PTT system and PTT Client solution. Section 5 presents the performance evaluation of the solution. The last section discusses some open issues and concludes the paper. II. BACKGROUND This Section starts with an overview of the IMS architecture focusing on the features relevant to the PTT service. The second part describes the PTT service and the key factors that have impact on the quality perceived by users of the service. A. IP Multimedia Subsystem The IMS is based on principles and protocols defined by IETF to take advantage of its large experience on the design of robust protocols, therefore reducing standardization and development efforts. The Session Initiation Protocol (SIP) [6], Diameter [7], Common Open Policy Service (COPS) [8], RealTime Transport Protocol (RTP) and RTP Control Protocol (RTCP) [9], are some of the protocols chosen for the IMS. SIP is the session control protocol for IMS [6]. It may be defined as a very flexible protocol for managing multimedia sessions over IP. A SIP session can include any type of media and any type of application. Therefore, a SIP session permits the sharing of a service context between a user and an application, or between two or more users. Each service within the SIP session can use its own protocols, and SIP 394 389 Authorized licensed use limited to: Soonchunhyang University. Downloaded on July 14,2010 at 00:37:55 UTC from IEEE Xplore. Restrictions apply. is just setting the framework for these protocols to be used between various endpoints. The simplified IMS Architecture, as in Figure 1, is a horizontal architecture composed by three layers: Transport, Control and Application. Figure 1. Simplified IMS architecture. The main components of this architecture are: Proxy Call Session Control Function (P-CSCF)–It is the first contact point within the IMS core network. This Function acts as an outbound/inbound SIP proxy server, providing user authentication and verification of correctness of SIP requests. Interrogator Call Session Control Function (I-CSCF)–It is located at the edge of an administrative domain and retrieves user location information for routing purposes. Serving Call Session Control Function (S-CSCF)–The core S-CSCF functionalities are user registration, interaction with service platforms and routing services while maintaining session state. Application Server (AS)–This key node is the service relevant part in the IMS. It is a SIP entity that hosts and executes services. AS interfaces are well defined, enabling developers to create services in an easy manner. Home Subscriber Service (HSS)–It is the central repository for user related information. It stores user profiles, security information and AS profiles. Media Resource Function (MRF)–It provides media related functions such as media manipulation (voice stream processing) and playing of ring-tones and announcements for the network. Breakout Gateway Control Function (BGCF)–It is a SIP server responsible for the selection of the network in which PSTN breakout is to occur. B. IMS Requirements The main features of IMS may be described by the following requirements [10]: Rapid service development: In the past, every service was either standardized or proprietary, but with the necessity of launching new services and combined services this is no longer acceptable. Nowadays it is fundamental to have a scalable service platform and to be able to launch services quickly. Quality of Service (QoS): One of the key objectives of IMS is to provide mechanisms to negotiate QoS. With IMS, the UE (User Equipment) can express capabilities and negotiate QoS requirements during a SIP Setup Procedure or SIP Modification Procedure. After the negotiation, at application level, the parameters are reserved. Charging Arrangements: These are among the most important requirements from the operator’s point of view as well as from the business model. It is by these Arrangements that IMS provides appropriate charging mechanisms. It is possible to use different charging schemes or even to correlate charging information generated at the transport, service and content charging levels. IMS also supports the usage of both online and offline charging capabilities. Interoperability: Interoperability has two major motivations: the fact that IMS will not be deployed all over the world at the same time and also the fact that other networks offer millions of potential destinations for sessions initiated in IMS. To be successful IMS has to be able to connect as many users as possible. Besides all this, interworking with Internet and circuit-switched networks will make the number of potential sources and destinations for multimedia to rise dramatically. The IMS combines the best of mobile networks and Internet to provide a set of services that can be used independently of the access network, such as: Push-To-Talk, Push-To-Watch, video-conference, sharing all types of files/information and Instant Messaging. C. Push-To-Talk The PTT service is a direct one-to-one and one-to-many voice communication system that works over cellular, wireless networks and even packet based data networks (like the Internet). PTT is based on half-duplex mode of communications and its implementation based on Voice over IP (VoIP) technology has turned it into one of the most used services to test IMS, due to its delay tolerance. The PoC is a PTT service provided on a cellular mobile network, designed for interoperability between other PoC services on different network operators. In this document PoC and PTT are treated as synonyms, due to the usage of OMA specifications. However, PoC is not restricted for usage only on cellular/mobile networks but also on fixed networks and the Internet, provided adequate “terminal” are available (typically “soft terminal”). Figure 2 shows the PTT components as specified by OMA [4]. In PTT, signaling and control sessions are based on SIP, and the voice traffic is transmitted with RTP/RTCP. Each talking client sends RTP/RTCP packets to the PTT server, and the server distributes the packets to the other session members. The main components of PoC/PTT are: 390 395 Authorized licensed use limited to: Soonchunhyang University. Downloaded on July 14,2010 at 00:37:55 UTC from IEEE Xplore. Restrictions apply. Turnaround Time (TaT)–Refers to the minimum possible duration after a user stop talking (releasing the floor) to the moment he/she starts hearing another user. It should not take more than 4 seconds. III. T HE IMS CORE AND PTT SYSTEM SOLUTION Figure 2. PTT components as specified by OMA [4]. PoC Client–It is a UE (User Equipment) functional entity that is able to register itself on the IMS network and supports the functionalities defined in [11]. It must be able to initiate/modify/terminate PTT sessions, generate and send talk bursts, receive and process talk bursts and support Talk Burst Control Protocol (TBCP) procedures. PoC Server–Contains the logic of the PTT service. It provides SIP session handling and talk burst control functionality. It is, in effect, an AS supporting call control function. XML Document Management Client (XDMC)–The XDMC is an XCAP client that manages XML with PTT specific information or shared information. Management features include operations such as create, modify, retrieve and delete. XML Document Management Server (XDMS)–The PTT XDMS is an XCAP server that manages XML documents specific to the PTT service (e.g., PTT groups). TBCP is the protocol that provides “floor control” during a PTT session. It is via TBCP that user requests for authorization to speak (get the floor), are granted, denied or revoked by the PTT AS. It is also via TBCP that the PTT AS informs the users if the floor is taken. TBCP, as defined by the OMA, uses the application extension features of RTCP to invoke floor control within the PTT environment. The implementation of the IMS core functions was done using the open platform SER (SIP Express Router) [13], based on the work already developed by FOKUS [5] and CAMPARI testbed [14]. From the AS point of view, SER implements the signaling, routing and registration in the same manner that IMS does. With this strategy it was possible to test the most important features of IMS, i.e., the signaling and the routing platform. In order to simplify the implementation, the XCAP function from the OMA architecture was replaced by a MySQL database to store the PTT specific information, as it would only be accessed by the PTT AS. With this option taken, the PTT Server system also played the role of Aggregation Proxy. As specific PTT information was only available to the PTT AS, the PTT Presence functionality has been implemented also in the PTT AS. D. Push-To-Talk Requirements Quality of Experience (QoE) is the term used to describe the users perception about the system and its usability [12]. In the Push-To-Talk service the key factors that have impact in the QoE are the following [4]: Right-To-Speak (RTS)–The duration between the time a user initiates a PTT session and the time he/she receives an RTS indication. It should be less than 2 seconds. Start-To-Speak (STS)–The duration between the time that a session participant initiates a floor request and the time he/she receives an STS indication. This should be less than 1.6 seconds. End-To-End channel delay (ETE)–During a session the channel delay should not be more than 1.6 seconds and not more than 4 seconds when initiating a new session. Voice Quality–Should meet the following limit: Mean Opinion Score (MOS) higher than 3 and Packet Error Ratio (PER) less than 2%. Figure 3. PTT on IMS solution. With the above options it was possible to recreate the IMS main services and make the usage of the PTT service enjoyable. The components of the solution are (see Figure 3): SIP/IP Core–It is the central element of the architecture. All SIP signaling goes through the core that is responsible to correctly forward and route all the signaling. It authenticates users and checks the validity of all SIP messages. Presence Server–It allows users and entities to follow the presence status of a specific user. However this presence module does not support specific application status, therefore it cannot be used to follow PTT service status. PTT Data Base–It replaces and implements functionalities of the XDMS element. It also stores the PTT subscriber’s 391 396 Authorized licensed use limited to: Soonchunhyang University. Downloaded on July 14,2010 at 00:37:55 UTC from IEEE Xplore. Restrictions apply. information and the existing PTT Groups. It is from the PTT DB that information is retrieved on the service capabilities of a user as well as on his/her group membership attributes. PTT Client–This client performs half-duplex conversations between groups of users. It has a simple interface based on common instant messaging applications style. It allows users to setup sessions with pre-assigned or ad-hoc user created groups. The audio codec used by the PTT Client program was the G.723.1 [15]. The client does not store any information locally; all user information (contact list and groups list) are stored and accessed by the PTT Server. PTT Server–It controls the session functions and makes it possible to setup, modify and tear-down PTT sessions; it also performs the audio distribution between all participants of a session and implements the TBCP protocol. Besides the OMA PTT Server functionalities it also plays other roles defined in the specifications: it performs the aggregation proxy role as all the PTT specific information must be accessed through it using SIP messages and implements the specific PTT presence status service, acting as a presence source. All flows passing through the SIP/IP core uses SIP signaling. The flow going from client to server and vice versa uses RTP and the flow to and from the PTT DB uses JDBC (Java Database Connectivity). A. The PTT Server The PTT AS has been developed with the initial goal of deploying a server capable of dealing with SIP signaling and audio distribution. The server followed a modular architecture with well-defined interfaces between each function. It was developed in Java, behaving like a Back-To-Back User Agent (B2BUA). The Server has the function of controlling the access to the service, because only PTT Subscribers can make PTT Calls. The PTT Server is responsible for saving contacts and each PTT Subscriber’s state. The main three modules of the PTT AS architecture that deserve a detailed description are the Session Manager, the Contact Manager and the JAIN SIP as they are the ones responsible for the implementation of all the application’s logic. Figure 4 illustrates the PTT AS architecture. Session Manager–It is the central block of the PTT session’s implementation in the AS. This is the block that allows the setup, modification and tear-down of PTT sessions. The Session Manager keeps track of all sessions. For each session in progress in the server it keeps an object session that works like a repository of session information. The Session Manager is responsible for implementing the session management and TBCP. The object session is responsible for receiving the audio for distribution to all session participants. This is done without processing the audio. The only processing done to RTP flow is to check the sequence number and avoid out of order transmissions. The Session Manager is also responsible for starting the TBCP mechanisms for each session and managing the floor control for each session. The Session Manager also performs charging functions, i.e., it generates Charging Data Records (CDRs) for each session. Figure 4. PTT AS architecture. Contact Manager–It deals with presence information and implements aggregation proxy functionality. It also manages the user’s contact list. The presence service was slightly changed in relation to the normal presence behavior. Usually a user requests information on members whose statuses he/she wants to know about. However, since the PTT AS knows the user’s contact list and groups, it was decided to make some changes to take advantage of the fact that from the contact list of a user and user’s groups it is possible to know the status of any other member he/she wants to follow. JAIN SIP–It is a low level API that maps directly to SIP. It was chosen for the implementation of all SIP functionalities needed by the PTT AS. DB module–It is responsible for DB accessing. It uses the framework Hibernate making the access to databases far easier by mapping the database content to objects [16]. This module is used by the Contact Manager to access the user’s information and group’s information. Util module–It is responsible for accessing and writing files and parsing strings whenever and wherever needed. It is used for PTT AS log writing, CDR files generation and user’s contact list access and edition. Authentication Module–It is used for computing the response to the Digest Authentication Challenge generated by the SIP / IP core. User Agent and Message Handlers implement the JAIN SIP interface to access the SIP stack. It is through the User Agent that messages received by the SIP stack are passed to the application level. B. Talk Burst Control Protocol (TBCP) The TBCP mechanism (also known as Floor Control) applied in this solution was not implemented as recommended by OMA. Under OMA recommendation the TBCP goes directly from the client to PTT AS. This causes some lack of flexibility and it is more complex than using SIP. In this solution the implementation of TBCP was made using SIP INFO messages as suggested in [17]. This allowed the separation of the application logic from the media handling. 392 397 Authorized licensed use limited to: Soonchunhyang University. Downloaded on July 14,2010 at 00:37:55 UTC from IEEE Xplore. Restrictions apply. By choosing to use SIP signaling for TBCP it was possible not only to separate these functions, but also to keep them integrated. This is an option that platform vendors and network operators must take into consideration. A possible scenario for the adoption of this alternative option is for an update/upgrade to a media server not requiring changes to the PTT AS and vice versa. It is also easier to have just one kind of signaling instead of having two different signaling protocols with associated increased complexity. The SIP INFO Messages created for Floor Control, were: SIP SIP SIP SIP SIP SIP SIP INFO INFO INFO INFO INFO INFO INFO TBCP TBCP TBCP TBCP TBCP TBCP TBCP A. The User State Diagram The User State Diagram suggested by OMA, illustrated in Figure 5, was used as reference for the implementation of the PTT Client [4]. When the Client Application is started the user is in the initial state, that is, in the state “User”. To interact with network services the user must first register, transiting to the State “Registered in the Network”. The registration in the network starts by sending a request message of type SIP REGISTER from the Client to the x-CSCF. In the “Registered Granted Deny Idle Taken Revoke Request Release Figure 5. The PTT Server sends the Granted, Deny, Idle and Taken messages to a client. The PTT Client sends the Request and Release messages to the PTT Server. The OMA suggests that TBCP Connect, TBCP Disconnect and TBCP Talk Burst Acknowledgement Messages should be used in pre-established sessions, but as this function wasn’t implemented it wasn’t necessary to apply these messages. As the queuing mechanism wasn’t implemented to Floor requests, it also wasn’t necessary to implement TBCP Talk Burst Request Queue Status Request and TBCP Talk Burst Request Queue Status Response Messages. IV. T HE PTT C LIENT The PTT Client is an application with a graphic mode developed in Java for Desktop. The Application contains a list of contacts that the user can add, modify or delete. As a PTT application it can capture audio from the microphone and reproduce audio on the device speakers. The PTT Client works as a SIP User Agent, able to register in the x-CSCF and send or receive SIP signaling messages. The PTT Subscriber has the possibility to see the PTT groups he belongs to, to establish group sessions with these or to a set of ad-hoc contacts or even a single subscriber. With the PTT application, the subscriber can express his state of presence in the x-CSCF. There is a configuration file that is loaded when the application is launched. This file contains the necessary fields including the IP Address, name, SIP Address and User’s key, PTT Server’s SIP Address, outbound/inbound SIP Proxy Address, among others. One of the most important components of the PTT Client is the Audio. Without audio all of the other application elements: interface, network registry, PTT registry, TBCP States, Presence, Contact List and PTT Groups would make no sense. In a PTT Service there are two audio components: send and receive. The Java Media Framework (JMF) was used to address all audio details. User State Diagram. in the Network” state, the user can interact with network services or express his state of presence. To change to state “Registered in the PTT Server” the client must inform the PTT Server of the intention to register. The PTT Server checks if the register request arrives from a known PTT Subscriber, that is, if the User’s SIP Address is in the data set SUBSCRIBER. Accepted in this state, the client may then invite other clients for a PTT Session or be available for an invitation. Either of these actions forces a transition to the “PTT Participant” State. In the “PTT Participant” State the client application can capture audio, encode and send it to the PTT Server or just play received audio streams. The client returns to the “Registered in the PTT Server” after leaving the session or being forced released from the session. In the “Registered in the PTT Server” State, the client may return to the “Registered in the Network” state by informing the PTT Server that it is no longer available for PTT Sessions. If the client application is in the “Registered in the Network” state, it can return back to the “User” state by informing the x-CSCF that it wants to cancel the registration. In this case, the user should send a SIP REGISTER message with the field EXPIRES to 0. B. Contacts Management Each PTT Subscriber has its own list of contacts that is kept in the PTT Server. After the client registration in the PTT Server, the Server replies with the contact list using a SIP INFO BuddyList Message composed by a XML File containing the contacts. In the example of Figure 6, the SIP INFO BuddyList Message contains the File “contactsIMS1.xml” in the first version. The subscriber then adds a new contact with the name “ims3” containing the SIP Address: sip:[email protected]. This action originates a SIP INFO AddBuddy Message (message 3). When receiving this message, the PTT Server sends a SIP 200 OK Message to confirm the reception and updates the contact list of PTT Subscriber changing “contactsIMS1.xml” file to version two. 393 398 Authorized licensed use limited to: Soonchunhyang University. Downloaded on July 14,2010 at 00:37:55 UTC from IEEE Xplore. Restrictions apply. Figure 6. Example of Contact update. The subscriber then decides to remove the contact with the address: sip:[email protected], and this action originates a SIP INFO RemoveBuddy Message (message 5). When the PTT Server receives this message it changes the file “contactsIMS1.xml” to version 3 and confirms the message reception sending a SIP 200 OK Message. After this, the subscriber decides to change the name of his friend “ims3” to “JOAO”. This action originates the sending of a SIP INFO RemoveBuddy Message (message 7) and after confirmation the sending of the message SIP INFO AddBuddy (message 9) with complete new user information. In this case, with the name “JOAO” and the SIP Address sip:[email protected]. This will change the “contactsIMS1.xml” File to version 4. The component x-CSCF was hidden from the example in order to simplify the explanation. C. Groups Management The information about PTT Groups is saved in the PTT Server. PTT Subscribers have access to this information by pressing a button “Import Groups” from their application. This action originates the sending of a SIP INFO message with the field Content-Type: application/GroupsQuery and in the body the SIP Address of the PTT Subscriber, for example sip:[email protected]. When receiving this message, the PTT Server makes a query to the database looking for PTT Groups where this Subscriber is a member. This information reaches the PTT Subscriber by a SIP INFO message with the field Content-Type: application/GroupsResponse and in the body a XML containing the group members information. Not only the SIP INFO BuddyList Message, but also the SIP INFO GroupsResponse is sent to the client every time he registers in the PTT Servers. The SIP INFO GroupsResponse Message is sent to clients every minute because PTT Groups information can be modified in the PTT Server. Consequently, the update time for clients is a maximum of one minute. D. Presence Management The PTT Client has two Presence Services: Network Presence Service (optional) and PTT Server Presence Service. For Network Presence the user may change his status for Online, Busy and Off-line. The Busy status is the one managed by the PTT Presence Service for keeping the PTT Status of each user. The PTT Presence Service is responsible for changing the status for On-line, In-Session, Off-line, and NA (Not Available). The inclusion of Presence Services is used not only to inform the users but also to define policies of PTT Session Establishment. When a PTT Client needs to setup a PTT Session for one or more users (Ad-hoc), he may only set it up if all selected users are in appropriate condition to also start a PTT Session. The appropriate condition is having an On-line status both for the Network Presence and the PTT Server Presence (or having a PTT Server Presence Status of On-line and the Network Presence Status disabled). Otherwise, the PTT Subscriber that is trying to setup the PTT Session will be notified and the session will not be allowed. For Group PTT Sessions, there must be at least two members of the group in an appropriate state, otherwise the client will be notified with an error message. V. P ERFORMANCE EVALUATION In order to verify the correct operation of the PTT solution a set of tests were performed not only to confirm system functionality but also to evaluate its ability to offer a satisfactory Quality of Experience (QoE) [12] by running them against the QoE requirements suggested by OMA [4], the RightTo-Speak (RTS), Start-To-Speak (STS), End-To-End channel delay (ETE), Voice Quality and Turnaround Time (TaT). The codec used was the G.723.1 (of 6.3 Kbps), which has an MOS of over three units [15], [18]. The tests were carried out in a high-bandwidth campus network (LAN) and in a CDMA2000 wireless network. In each test several samples were taken for each of the QoE performance parameters. Tables I and II resume the average, median, standard deviation, minimum and maximum sample values for the tests carried out in the LAN and in the CDMA2000 networks, respectively. The results on a LAN environment Table I R ESULTS IN A LAN. RTS (ms) STS (ms) PER (%) ETE (ms) TaT (ms) Average Median Deviation Maximum Minimum 668.3 671.0 176.4 985.0 390.0 95.4 90.0 48.5 375.0 31.0 1.42 1.37 0.87 3.65 0.00 47.1 18.0 129.8 920.0 0.0 413.7 384.0 198.4 1355.0 267.0 OMA Limits 2000 1600 2.00 1600 4000 were fairly good, with average and median values within the limits defined by OMA. For PER (Packet Error Rate) there were observed some maximum values beyond the limit but those were due to network conditions, not to the behavior of the solution. Median value also indicates that more than 50% 394 399 Authorized licensed use limited to: Soonchunhyang University. Downloaded on July 14,2010 at 00:37:55 UTC from IEEE Xplore. Restrictions apply. Table II R ESULTS IN A CDMA2000 N ETWORK . Average Median Deviation Maximum Minimum OMA Limits RTS (ms) STS (ms) PER (%) ETE (ms) TaT (ms) 3024.0 2292.0 1830.7 5468.0 1312.0 675.5 555.5 369.0 1642.0 328.0 2.56 2.60 0.24 2.89 2.10 511.4 436.5 390.9 2036.0 14.0 1954.3 1937.5 508.9 2859.0 1264.0 2000 1600 2.00 1600 4000 The performance tests produced good results and helped to understand why PTT is in the front line when talking about IMS. Although some QoE requirements were not perfectly met, mainly over the CDMA2000 network, a user of PTT service over such a network will quite certainly receive a good user experience. of all tests produced results within the specified limits. On CDMA2000 the results were also fairly good. Although RTS values may seem on critical levels, as their average and median values went beyond the defined performance limits, they result from the following conditions: 1) The spiky nature of the CDMA2000 RLP (Radio Link Protocol) processing; 2) Non-optimization for the “dormancy” state of the radio link (traffic channels tear-down after a few seconds of inactivity, typically 10 to 15 seconds); 3) Both PTT client and the PTT server located at the cdma2000 access network. The values for PER were also beyond limits but perfectly tolerable, considering the harsh radio environment of the CDMA2000 access network. For the QoE Voice Quality the adoption of the G.723.1 codec at 6.3 Kbps with an average MOS of 3.46 proved to be adequate [19]. The higher MOS, compared with the OMA limit value, makes the sound quality more tolerant to PER due to a larger margin of error supported. VI. C ONCLUSION IMS is no doubt a powerful architecture. The common functions, like signaling and routing, provide a powerful framework to easily deploy a Service or Application. The solution developed for Push-To-Talk could very easily support another AS for Push-To-Video or other Media without to the need to make changes to the core of the network or to know about the access networks used; the only elements that would have to be changed or added would be the ASs (additional functions or applications) and the client applications. The solution designed for the PTT Talk Burst Control showed very interesting results and great flexibility when compared to the TBCP specified by OMA. The capability to separate the application logic from the media functions is very interesting and additionally it follows 3GPP’s IMS principles, for the reuse of the media functions by other multimedia nodes and the modification of individual components not requiring changes to the others. The PTT Presence service implementation adopted for this solution is also an important example of the synergies that IMS allows between different services, promoting, in this case, a significant reduction of the overall number of presence messages in the network. ACKNOWLEDGMENT This work was supported by Zapp–Radiomóvel Telecomunicações SA, Portugal, that provided the technical conditions and the mobile equipment used for the development and testing of the solution, under its nationwide 3G CDMA2000 mobile radio network. R EFERENCES [1] G. Camarillo and M. Martı́n, The 3G IP Multimedia Subsystem (IMS), 2nd ed. John Wiley and Sons, 2006. [2] M. Poikselkä, G. Mayer, H. Khartabil, and A. Niemi, The IMS: IP Multimedia Concepts and Services, 2nd ed. John Wiley and Sons, 2006. [3] ETSI, “TISPAN-Telecoms and Internet converged Services and Protocols for Advanced Networks.” [Online]. Available: http://www. etsi.org/tispan/ [4] OMA, “Push to talk over Cellular (PoC) – Architecture,” Open Mobile Alliance (OMA), Specification Approved Version 1.0.1., November 2006. [5] T. Magedanz, D. Witaszek, and K. Knuettel, “The IMS playground @ FOKUS-an open testbed for next generation network multimedia services,” Tridentcom, Tech. Rep., February 2005. [6] J. Rosenberg, H. Schulzrinne, G. Camarillo, and et al., “RFC3261 - SIP: Session Initiation Protocol,” Internet Engineering Task Force (IETF), Tech. Rep. RFC 3261, August 2004. [7] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, and J. Arkko, “RFC3588 - Diameter Base Protocol,” Internet Engineering Task Force (IETF), Tech. Rep. RFC 3588, September 2003. [8] D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, and A. Sastry, “RFC2748 - The COPS (Common Open Policy Service) Protocol,” Internet Engineering Task Force (IETF), Tech. Rep. RFC 2748, January 2000. [9] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RFC3550 - RTP: A Transport Protocol for Real-Time Applications,” Internet Engineering Task Force (IETF), Tech. Rep. RFC 3550, July 2003. [10] 3GPP2, “All-IP Core Network Multimedia Domain – Overview, Version 2.0,” 3rd Generation Partnership Project 2 (3GPP2), Tech. Rep. X.S0013-000-0-v2.0, August 2005. [11] 3GPP, “Network Architecture,” 3rd Generation Partnership Project (3GPP), Tech. Rep. TS 23.002, June 2007. [12] ITU-T, “Definition of Quality of Experience (QoE),” International Telecommunications Union, Tech. Rep. P.10/G.100-Ammendment 1, January 2007. [13] IPTEL, “SIP Express Router (SER).” [Online]. Available: http: //www.iptel.org/ [14] J. Fabini, P. Reichl, A. Poropatich, R. Huber, and N. Jordan, “IMS in a Bottle: Initial Experiences from an OpenSER-based Prototype Implementation of the 3GPP IP Multimedia Subsystem,” Mobile Business, 2006. ICMB ’06. International Conference on, pp. 13–13, June 2006. [15] ITU-T, “Dual Rate Speech Coder for Multimedia Communication Transmitting at 5.3 and 6.3 kbit/s,” International Telecommunications Union, Tech. Rep. G.723.1, March 1996. [16] HIBERNATE, “Hibernate.” [Online]. Available: http://www.hibernate. org/ [17] N. Blum and T. Magedanz, “PTT + IMS = PTM - towards community/presence-based IMS multimedia services,” Multimedia, Seventh IEEE International Symposium on, pp. 8 pp.–, Dec. 2005. [18] ITU-T, “Mean Opinion Score (MOS) terminology,” International Telecommunications Union, Tech. Rep. P.800.1, July 2006. [19] A. Ramo and H. Toukomaa, “On comparing speech quality of various narrow- and wideband speech codecs,” Signal Processing and Its Applications, 2005. Proceedings of the Eighth International Symposium on, vol. 2, pp. 603–606, 28-31, 2005. 395 400 Authorized licensed use limited to: Soonchunhyang University. Downloaded on July 14,2010 at 00:37:55 UTC from IEEE Xplore. Restrictions apply.