Push-to-talk Performance over GPRS Andras Balazs Siemens AG, Communications Hofmannstr. 51, D-81359 Munich, Germany Tel. 49-89-722-27714
[email protected] 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.
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.
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.
Categories and Subject Descriptors B.8.2 [Performance Analysis and Design Aids] mobile network, IP traffic flow, bandwidth, delay
2. PUSH-TO-TALK IN GPRS NETWORKS
General Terms
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].
Measurement, Performance, Design, Standardization
Keywords Push-to-Talk, Performance, GPRS
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).
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.
2.1 Bearer Concept For the performance analysis we assume that the GPRS network provides QoS support according to 3GPP Release 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.
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 1-58113-953-5/04/0010...$5.00.
182
E2E IP Bearer External Network Bearer
UMTS/GPRS Bearer
MT TE
R
BTS Um
BSC Abis
Gb
SGSN Gn GGSN
Gi
IMS & PoC Servers
Multi Layer Switch
IP packet flow ing 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.
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.
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.
Table 1: PoC Release 1.0 End-to-end Delay Recommendations PoC Message Flow
Session Control
Floor Control
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)
User Plane
E2E Delay [s]
The delay values for PoC Session Set-up, Early media flows in the 4th column of the table illustrate how signaling compression 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 compression rate of about 70%. With this rate of SIP message compression, 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 compression is not necessary, nor suggested.
0.8
Voice Transfer (One-way)
1.6
Immediate Response
4.0
Table 2: Bandwidth Requirements of PoC Signaling Flows
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.
PoC Signaling Flows
Session Control
3. 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, find-
Floor Control
183
Bandwidth [kbps]
E2E Delay [ms]
Protocol, Compression Rate
22.44
3.040
SIP, 0%
11.22
2.012
SIP, 50%
6.73
1.570
SIP, 70%
4.49
1.340
SIP, 80%
UL
0.28
n.a.
RTCP, 0%
DL
0.60
n.a.
RTCP, 0%
Direction
UL/DL
codec used and of the radio receive conditions (coding scheme used) in the current radio cell of the PoC user.
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.
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, compression mechanisms can be applied to the IP flows if the underlying GPRS network supports them. The impact of UDP/IP header compression [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 3: Radio Link Capacity Usage of IP Packets with Voice Payload PoC Voice Flow
# of Voice Samples per IP Packet, Bandwidth requirement [kbps]
Direction
1
2
4
8
10
RTP, AMR 4.75
UL/DL
25.6
15.4
10.3
7.8
7.2
RTP, AMR 5.15
UL/DL
26.0
15.8
10.7
8.2
7.6
RTP, AMR 12.2
UL/DL
34.2
23.8
18.6
16.0
15.4
Table 4: Efficiency Gain, UDP/IP Header Compression, Delay PoC Voice Media
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).
UDP/IP HC
# of Voice Samples per IP Packet, One-way Delay (R – Gi) [ms] 1
2
4
8
10
RTP, AMR 4.75
yes
253.9
254.5
335.7
458.0
499.1
RTP, AMR 4.75
no
294.5
335.1
376.2
498.6
537.7
13.8
24.0
10.8
8.1
7.5
Efficiency gain [%]
Bandwidth requirement and Delay for PoC Voice Flow 25,00
AMR 4,75 AMR–IF2, no header compression
20,00
AMR 4,75 AMR–IF2, with header compression
1700,0
1600 ms
1300,0
18,6 kbps (CS4) 1100,0
15,00 900,0
13,4 kbps (CS3) 11,2 kbps (CS2)
700,0 10,00
Bandwidth [kbps]
Round Trip Delay [ms]
1500,0
AMR 5,15 AMR–IF2, no header compression
AMR 5,15 AMR–IF2, with header compression
7,4 kbps (CS1)
500,0
300,0
5,00 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Number of Voice Samples
Figure 2: Bandwidth Requirement and Delay of IP Packets with Voice Payload
Table 4 above shows the impact of header compression 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
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
184
load 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:
number of voice frames per packet increases. Header compression also increases the efficiency of radio link capacity usage as seen on Table 5. Table 5: Efficiency Gain, UDP/IP Header Compression, Bandwidth UDP/IP HC
PoC Voice Media
# of Voice Samples per IP Packet Bandwidth [kbps] 1
2
4
8
10
RTP, AMR 4.75
yes
16.8
11.0
8.1
6.6
6.4
RTP, AMR 4.75
no
25.6
15.4
10.3
7.8
7.2
34.4
28.6
21.4
15.4
11.1
Efficiency gain [%]
msgLength n= blockSize
n t = 20ms ⋅ + 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.
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 compression should always be used if the mobile terminal and the SGSN of the GPRS core support it.
3.3 GPRS Transport Delay 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.
Interface / Node
GPRS Transport Delay of PoC Voice (AMR 4,75, 8 frames) Packet TE R-I/F MT Um BTS Abis BSC Gb SGSN Gn GGSN Gi B.B. PoC B.B. Gi GGSN Gn SGSN Gb BSC Abis BTS Um MT R-I/F TE 0,0
180,0
0,0 10,0
160,0 5,0 20,0 18,0 1,5 17,8 0,2 0,6 0,0 0,0
50,0 0,0 0,0 0,4 0,2 18,5 1,9
29,0 20,0 5,0
160,0 10,0 0,0
100,0
200,0
300,0
400,0
500,0
600,0
700,0
180,0 800,0
900,0
Delay [ms]
Figure 3: GPRS Transport Delay Budget of Voice Packets Table 6: Typical GERAN TBF Establishment Delays
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.
TBF Establishment Procedure
Uplink TBF
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 pay-
Downlink TBF
185
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
100
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).
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.
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.
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.
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. •
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
Service Interruption Time [s]
3GPP Feature
Same LAC/RAC
4.5 - 5.0
3GPP Release 97/98
Different LAC/RAC
6.5 – 7.0
3GPP Release 97/98
No improvement
3GPP Release 99
1.0
3GPP Release 6 (draft)
•
•
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.
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.
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.
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
186
[6] Push-to-talk over Cellular (PoC), PoC Release 1.0, 08.2003, Ericsson, Motorola, Nokia, Siemens
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] 3GPP TS 21.102, 3rd Generation mobile system Release 4 specifications [8] 3GPP TS 23.107, Quality of Service (QoS) Concept and Architecture
7. REFERENCES
[9] 3GPP TS 23.207, End-to-End QoS Concept and Architecture (Release 5)
[1] GSM 03.60, General Packet Radio Service (GPRS); Service Description [2] IETF RFC 2507, UDP/IP Header Compression
[10] 3GPP TS 24.229, IP Multimedia Call Control Protocol based on SIP and SDP; (Release 5)
[3] IETF RFC 3267, RTP payload format & file storage for AMR Audio Codecs
[11] 3GPP TS 26.071, Mandatory Speech Codec speech processing functions; AMR Speech Codec; General description
[4] IETF RFC 3486: Compressing the Session Initiation Protocol (SIP) [5] IETF RFC 3550, RTP: A Transport Protocol for Real-Time Applications
187
