Push-to-talk Performance over GPRS

Transcription

1 Push-to-talk Performance over GPRS Andras Balazs Siemens AG, Communications Hofmannstr. 51, D Munich, Germany Tel ABSTRACT The paper considers end-to-end quality of service (QoS) aspects of the upcoming PoC (Push-to-talk over Cellular) service. Derived from the quality and performance requirements on signaling and media flows of this service, GPRS mechanisms and service parameters are discussed, which have significant influence on the end-user experience of the service. The impacts of mobile network elements are analyzed in terms of delay and bandwidth along the end-to-end transport path of GPRS networks. The paper concludes with an outlook on service quality enhancements, which will be possible with the deployment of the service in Enhanced GPRS and UMTS networks. Categories and Subject Descriptors B.8.2 [Performance Analysis and Design Aids] mobile network, IP traffic flow, bandwidth, delay General Terms Measurement, Performance, Design, Standardization Keywords Push-to-Talk, Performance, GPRS 1. INTRODUCTION The Push-to-talk application allows point-to-point, or point-tomultipoint voice communication between mobile network users. The communication is strictly unidirectional, where at any point of time only one of the participants may talk (talker), all other participants are listeners. In order to get the right to speak, listeners first have to push a talk button on their mobile terminals. Floor control mechanisms ensure that the right to speak is arbitrated correctly between participants. The PoC application may become a highly popular service for the mobile telecommunications market if its responsiveness and voice quality meet end-user expectations. The service has large potential for mobile operators, as well, since the IP based service promises highly efficient utilization of available GPRS network capacities. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. MSWiM 04, October 4 6, 2004, Venezia, Italy. Copyright 2004 ACM /04/ $5.00. However, the implementation of PoC with the required end-toend quality and performance in current GPRS networks is a challenging task, since the design of the GPRS packet switched (PS) domain has had data applications, like Web browsing and file download in focus. QoS support for real-time services - and the PoC service has a real-time voice component is not yet available. Most importantly, guaranteed bandwidth and a strictly limited end-to-end delay for the transfer of IP packets are not yet ensured. The paper shows, how the recommended service level could be implemented for PoC with currently available mechanisms in GPRS networks. QoS and performance issues of the PoC service are investigated in an end-to-end perspective. Emphasis is put on the GPRS access network, because it is the bottleneck concerning available link capacity and concerning QoS support. 2. PUSH-TO-TALK IN GPRS NETWORKS In order to ensure interoperability between PoC solutions of different vendors, the process of standardization of PoC services has begun. A first definition of PoC services, architecture, interfaces and protocols is already available from the vendor consortium EMNS [6]. The quality and performance of this service is significantly impacted by the behavior of the GPRS access network [1]. Since all IP based flows of the PoC application (session and floor control flows, voice media flows) are traversing the GPRS access network as user plane traffic, we consider the network elements of the GPRS user plane, which are traversed and have impact on the performance of PoC (see Figure 1). 2.1 Bearer Concept For the performance analysis we assume that the GPRS network provides QoS support according to 97/98 [8] and that the mobile terminal is always attached to the GRPS network. It is also assumed that one PDP context is established for the exchange of PoC session and floor control and voice messages. Separate bearers for signaling and media flows with different QoS parameter settings would also be possible, but would not essentially modify the results of our performance analysis. More important is the requirement that the PoC flows should not consume more than the radio link capacity of one timeslot in order to allow for the use of simple mobile terminals not supporting multiple timeslots in the uplink direction. 182

2 UMTS/GPRS Bearer E2E IP Bearer External Network Bearer MT BTS BSC R SGSN GGSN Um Abis Gb Gn Gi TE Multi Layer Switch IMS & PoC Servers Figure 1: PoC over GPRS, User Plane 2.2 Performance Requirements The performance design of the PoC application has to ensure that E2E delay recommendations of the PoC standard [6] for time critical message flows are met. The recommended delay values are shown in Table 1 below. Table 1: PoC Release 1.0 End-to-end Delay Recommendations Session Control Floor Control User Plane PoC Message Flow E2E Delay [s] Session Set-up, Early media 2.0 Session Set-up, Early session 2.0 Session Set-up, Late media 4.0 Session Join-in 4.0 Session Release 4.0 Floor Request (Right-to-speak) 1.6 Floor Release (State Change Notification) The Immediate Response time is an interesting figure to measure the responsiveness of the application, but it is not an objective measure, since it includes human reaction times in addition to the delays caused by Floor Release, Floor Request and by the subsequent Voice Transfer. All other metrics should be strictly maintained. In addition to the above delay requirements, the PoC design should ensure a voice quality that compares to the quality of GSM circuit-switched (CS) voice calls. The PoC Release 1 standard [6] recommends a packet loss rate for voice frames 2% and MOS 3 for voice quality perception. 0.8 Voice Transfer (One-way) 1.6 Immediate Response PoC PERFORMANCE It is the task of performance engineering to identify those means for the PoC application and in the GPRS access network, which in sum are capable of ensuring the quality and performance goals of the PoC service, given the assumptions on GPRS bearer usage as mentioned above. From several possible means for performance optimizations, like the optimization of PoC message flows, finding the optimal PDP context QoS profile settings and the right parameter values for GPRS network dimensioning and configuration, we show on examples, how PoC flows can be adapted to radio network characteristics and to varying radio link conditions. 3.1 PoC Signaling The PoC standard uses SIP based signaling for session control purposes [10]. Since SIP is a verbose protocol, its unmodified use in radio access networks would either lead to unacceptable session setup delays, or would increase the required radio link bandwidth significantly. Table 2 shows the bandwidths needed by PoC signaling flows in UL and DL directions for a given PoC user, if the PoC Release 1 delay recommendations are to be met. The delay values for PoC Session Set-up, Early media flows in the 4 th column of the table illustrate how signaling affects delay. The figures are results of detailed delay analysis of the flow using measurements in a GPRS network with Siemens BR7.0, GR 2.0 network elements. As it is seen from the table the requirement of using only one timeslot for PoC communications can be met if the SIP messages used in PoC session setups are SigComp compressed [4] with a rate of about 70%. With this rate of SIP message, the E2E delay recommended by Table 1 can also be met. Since the RTCP messages used for floor control do not require much radio link capacity, their is not necessary, nor suggested. Table 2: Bandwidth Requirements of PoC Signaling Flows PoC Signaling Flows Session Control Floor Control Direction UL/DL IP packet flow Bandwidth [kbps] E2E Delay [ms] Protocol, Compression Rate SIP, 0% SIP, 50% SIP, 70% SIP, 80% UL 0.28 n.a. RTCP, 0% DL 0.60 n.a. RTCP, 0% 183

3 3.2 PoC Voice Media According to [6], PoC voice media is carried over the GPRS network as a sequence of RTP [5] packets with constant bit rate, where the voice payload is encoded with narrow band AMR codec [3]. The RTP/UDP/IP headers of these IP packets represent a significant portion of the overall packet length. The overhead can amount to a multiple of the voice payload if a low bit rate AMR codec is used. Without taking any measures to reduce this overhead, the radio capacity consumption of PoC would be inhibiting high. Because of the half-duplex nature of voice communications in PoC a larger E2E delay is acceptable (refer to Table 1). This makes the packaging of more than one voice frame into one IP packet possible and can help reduce the RTP/UDP/IP protocol overhead. Table 3 below shows some examples for radio link capacity usage that would be necessary to carry PoC voice over GPRS in dependence of the AMR codec used and of the number of voice samples packed in one IP packet. Table 3: Radio Link Capacity Usage of IP Packets with Voice Payload PoC Voice Flow Direction # of Voice Samples per IP Packet, Bandwidth requirement [kbps] RTP, AMR 4.75 UL/DL RTP, AMR 5.15 UL/DL RTP, AMR 12.2 UL/DL As it is seen from the table the requirement of using only one timeslot for PoC communications can be met if low bit rate AMR codec is used (e.g. AMR 4.75 or AMR 5.15) and the number of voice samples per IP packet is large (typically 8). codec used and of the radio receive conditions (coding scheme used) in the current radio cell of the PoC user. If we take, for example the default CS2 coding scheme among typical radio link receive conditions, the number of voice samples that can be packed in one IP packet is 5 n 17 using PoC default AMR 5.15 codec. As a consequence, the one-way delay of voice transmissions will lie between 650 ms t 1520 ms. If radio link conditions deteriorate and the use of CS1 encoding becomes necessary over the radio link, the range of possible number of voice samples reduces to 12 n 17. This will lead to a higher one-way delay of about 1200 ms t 1520 ms if we use the same AMR encoding. However, switching back to an AMR 4.75 codec, a smaller number of voice samples per IP packet becomes possible again (1 0 n 17) and the minimal E2E delay can be reduced to 980 ms. In addition to the user plane adaptation strategy implemented by the PoC application, mechanisms can be applied to the IP flows if the underlying GPRS network supports them. The impact of UDP/IP header [2] on bandwidth usage and E2E voice transfer delay can also be seen on the Figure. The impact also depends on the number of voice samples per IP packet. Table 4: Efficiency Gain, UDP/IP Header Compression, Delay PoC Voice Media UDP/IP HC # of Voice Samples per IP Packet, One-way Delay (R Gi) [ms] RTP, AMR 4.75 yes RTP, AMR 4.75 no Efficiency gain [%] Bandwidth requirement and Delay for PoC Voice Flow 1600 ms 25,00 AMR 4,75 AMR IF2, no header 150 Round Trip Delay [ms] ,6 kbps (CS4) 13,4 kbps (CS3) 11,2 kbps (CS2) 20 15,00 10 Bandwidth [kbps] AMR 4,75 AMR IF2, with header AMR 5,15 AMR IF2, no header AMR 5,15 AMR IF2, with header 50 7,4 kbps (CS1) 30 5, Number of Voice Samples Figure 2: Bandwidth Requirement and Delay of IP Packets with Voice Payload The possible and useful range of adapting the transfer of IP packets with voice payload can be seen on Figure 2. The Figure shows the limits of voice frame packaging in dependence of the AMR Table 4 above shows the impact of header on the GPRS transport delay (between the R and Gi interfaces) for some selected values. The efficiency gain is larger if a small number of voice frames are packed into one IP packet. It decreases as the 184

4 number of voice frames per packet increases. Header also increases the efficiency of radio link capacity usage as seen on Table 5. Table 5: Efficiency Gain, UDP/IP Header Compression, Bandwidth PoC Voice Media UDP/IP HC Since the efficiency gain both in terms of radio link bandwidth (>11%) and in terms of GPRS transport delay (>8%) remains significant even with several voice frames per IP packet, UDP/IP header should always be used if the mobile terminal and the SGSN of the GPRS core support it. 3.3 GPRS Transport Delay # of Voice Samples per IP Packet Bandwidth [kbps] RTP, AMR 4.75 yes RTP, AMR 4.75 no Efficiency gain [%] A detailed analysis of the GPRS transport delay budget reveals that a significant portion of the overall delay is contributed by the thin wire of the radio link. Figure 3: GPRS Transport Delay Budget of Voice Packets Figure 3 shows the delay distribution of IP packets with voice payload over GPRS. It is remarkable that using the assumptions of the current analysis the GERAN delay budget (R - Gb) accounts for 91.8% of the overall GPRS transport delay budget (R Gi) for one-way (UL+DL) voice packet transmissions. The largest singular delay component of the GERAN delay budget is the transport delay over the Um interface. This is primarily due to the low bandwidth of the radio link that uses one GPRS timeslot with CS1 encoding. The Um transport delay can easily be explained by the number of radio blocks that are necessary to carry the IP packet. The transmission of the header compressed IP packet with the given payload requires 7 radio blocks. The resulting one-way delay over the Um interface (160 ms as seen on the Figure) can be calculated in a GERAN under target load (i.e. without queuing delays in BTS and BSC) as follows: msglength n = n t = 20 ms blocksize + 20ms timeslots The step-wise increase of the E2E delay in dependence of the number of voice samples per IP packet in Figure 2 can also be explained by the necessary number of radio blocks. 3.4 GERAN TBF Establishment Delay In the E2E delay analysis of PoC flows we have assumed that a radio channel with the necessary capacity is already available as the IP packets begin to be transmitted. This is, however, not always the case in GPRS networks. A radio channel (with a Temporary Block Flow TBF) is first established if an LLC frame with the first IP packet arrives for transmission. Thus, an additional delay for the establishment of a TBF has to be added to the pure IP packet transport delays. Typical TBF establishment times in GERAN are summarized Table 6. The rows in the Table represent different circumstances in which radio channel establishments may happen. It depends on the timing relationship between messages in a PoC flow, which of the TBF establishment delays occurs. Interface / Node GPRS Transport Delay of PoC Voice (AMR 4,75, 8 frames) Packet R-I/F TE Um MT BTS Abis BSC SGSN Gb GGSN Gn Gi B.B. PoC B.B. GGSN Gi SGSN Gn BSC Gb Abis BTS Um MT R-I/F TE ,0 2 18,0 1,5 17,8 0,2 0,6 5 0,4 0,2 18,5 1,9 29,0 2 5, Delay [ms] Table 6: Typical GERAN TBF Establishment Delays TBF Establishment Procedure Uplink TBF Downlink TBF Circumstances Typical Delay [ms] Channel is not yet active 300 No concurrent DL TBF 250 Concurrent DL TBF exists 150 Channel is not yet active 230 No concurrent UL TBF 160 Concurrent UL TBF exists

5 It is important for the PoC design to account for these delays. One example is the transfer of voice bursts. Here, the one-way delay variation caused by the GPRS access network has to be smoothen out with a jitter buffer at the receiving side of the voice burst (at the listener). The size of the jitter buffer must be sufficient enough to store digitalized voice samples of at least the duration of TBF establishments. However, the length of the jitter buffer is a constant component of the end-to-end delay and should, thus, be kept low. If the GPRS network supports Extended UL TBF feature [7], the UL TBF can be kept active for the whole duration of voice bursts. In this case, the jitter buffer does not have to care for delay variations caused by TBFs and the one-way voice burst delay can significantly be reduced. Even if an existing TBF can be kept alive during the complete PoC message flow, it is not guaranteed by the GRPS network that the bandwidth needed by the given PoC flow remains available. Congestion in the radio cell, or the degradation of radio receive conditions may lead to the reduction of radio link capacity allocated to the given TBF. This may cause prolonged delays in PoC control flows, but even worse, it can lead to unacceptable voice quality caused by high loss rates of IP packets during voice burst transmissions. 3.5 Impact of Mobility Another problem for the quality and performance of the PoC application is caused by the missing support of soft hand-over for GPRS PS domain traffic. The table below summarizes typical delay values due to cell reselection caused by mobility of the PoC user. Table 7: Service Interruption Times Due to Cell Reselection Mobility Function Cell Reselection Network Controlled Cell Reselection (NCCR) Network Assisted Cell Change (NACC) Location Area, Routing Area Same LAC/RAC Different LAC/RAC Service Interruption Time [s] No improvement 3GPP Feature 97/98 Long service interruption times will cause losses of IP packets (LLC frames) during GERAN cell reselections. Packet loss in turn leads to retransmissions of PoC signaling messages, which will cause significantly higher E2E delays. Though these delays will definitely exceed PoC standard recommendations e.g. for PoC session set-up, they will be tolerated by PoC users, because they will occur only in certain PoC scenarios and remain infrequent exceptions to the normal case. The consequences of packet loss for voice quality are worse. Since the service interruption times caused by cell changes are comparable to the duration of PoC voice bursts (6-10 s), in worst / (draft) case, complete sentences may get lost. Since the talker does not recognize that some of the listeners have lost a speech fragment, the listeners will have to ask to talker to repeat the lost sentence (after they have pushed the button and have got the right to speak). Since the PoC user plane adaptation mechanisms defined in [6] to adjust voice encoding and packaging to radio receive conditions (as mentioned in chapter 3.2, Figure 2) cannot distinguish between packet losses caused by cell reselection and by the deterioration of receive conditions in the serving cell, cell reselections will trigger an inappropriate adaptation of voice traffic. This example shows that further work on PoC voice traffic adaptation to varying radio link conditions is still needed in order to ensure voice quality in GERAN cells. 4. OUTLOOK It will gradually be possible to remove the quality and performance drawbacks of PoC service deployment in GPRS networks as more support for real-time services is going to become available [9]. The following list names examples for Enhanced GPRS and UMTS features, which will bring quality and performance improvements for the PoC service. The higher radio cell capacity of EDGE and UTRAN will allow for allocating more bandwidth for GPRS data traffic and will thus be able to support of more PoC users per radio cell. This will also allow for faster session setups and floor control procedures and increase the responsiveness of the PoC service toward the end-user. More radio link coding schemes in EGPRS will allow for a more efficient use of available radio cell capacities. The Extended UL TBF feature will help blocking an active TBF during voice bursts and time critical PoC signaling flows (e.g. session set-up). The support of real-time bearers over the Gb interface will guarantee the availability of the minimum required bandwidth over the radio link during voice transmissions. It will make a PoC voice quality possible that is comparable to that of GSM CS calls. The implementation of the NACC feature in the PS domain of GPRS will significantly reduce service interruption times due to cell reselection down to a value, which is comparable to hand-over times in the CS domain. 5. CONCLUSION The PoC service design possesses mechanisms, which allow for its deployment in current GPRS networks if the GPRS bearer parameters are carefully selected and the GERAN cells are appropriately configured for GPRS data traffic. The recommended PoC service quality level can be maintained as long as the target load of the network is not exceeded. However, neither the recommended end-user delays of PoC session and flow control flows, nor the required quality of PoC voice media transmissions can be guaranteed in a congested GPRS network, because of lacking bandwidth guarantees for PS domain traffic. Guaranteed PoC service quality will be achievable in congested environments with the upcoming deployment of EGPRS and UMTS networks, where QoS support for real-time traffic is going to be provided. 186

6 6. ACKNOWLEDGMENTS The author would like to thank his colleagues Abdollah Eslami and Johann Bauer for their contributions to the performance analysis of the PoC service, and Dietmar Weber for his valuable review comments. 7. REFERENCES [1] GSM 03.60, General Packet Radio Service (GPRS); Service Description [2] IETF RFC 2507, UDP/IP Header Compression [3] IETF RFC 3267, RTP payload format & file storage for AMR Audio Codecs [4] IETF RFC 3486: Compressing the Session Initiation Protocol (SIP) [5] IETF RFC 3550, RTP: A Transport Protocol for Real-Time Applications [6] Push-to-talk over Cellular (PoC), PoC Release 1.0, , Ericsson, Motorola, Nokia, Siemens [7] 3GPP TS , 3rd Generation mobile system Release 4 specifications [8] 3GPP TS , Quality of Service (QoS) Concept and Architecture [9] 3GPP TS , End-to-End QoS Concept and Architecture (Release 5) [10] 3GPP TS , IP Multimedia Call Control Protocol based on SIP and SDP; (Release 5) [11] 3GPP TS , Mandatory Speech Codec speech processing functions; AMR Speech Codec; General description 187