See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/221454010

Push-to-talk performance over GPRS

Conference Paper January 2004

DOI: 10.1145/1023663.1023697 Source: DBLP

CITATIONS READS

13 37

1 author:

Andras Balazs
Nokia Networks, Germany, Ulm
3 PUBLICATIONS 14 CITATIONS

SEE PROFILE

Available from: Andras Balazs

Retrieved on: 06 August 2016
 Push-to-talk Performance over GPRS
Andras Balazs
Siemens AG, Communications
Hofmannstr. 51, D-81359
Munich, Germany
Tel. 49-89-722-27714
andras.balazs@siemens.com
ABSTRACT
The paper considers end-to-end quality of service (QoS) aspects
of the upcoming PoC (Push-to-talk over Cellular) service. De-
rived 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 con-
cludes 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-to-
multipoint 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, listen-
ers first have to push a talk button on their mobile terminals.
Floor control mechanisms ensure that the right to speak is arbi-
trated 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.
MSWiM04, October 46, 2004, Venezia, Italy.
Copyright 2004 ACM 1-58113-953-5/04/0010...$5.00.
182
However, the implementation of PoC with the required end-to-
end quality and performance in current GPRS networks is a chal-
lenging 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 avail-
able. Most importantly, guaranteed bandwidth and a strictly lim-
ited 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 dif-
ferent 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 signifi-
cantly 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 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 ex-
change 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 essen-
tially modify the results of our performance analysis. More impor-
tant 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.
 E2E IP Bearer
External Network
UMTS/GPRS Bearer Bearer

MT BTS BSC
R SGSN Gn GGSN Multi Layer IMS & PoC
Um Abis Gb Gi Servers
TE Switch

IP packet flow
ing the optimal PDP context QoS profile settings and the right
Figure 1: PoC over GPRS, User Plane parameter values for GPRS network dimensioning and configura-
tion, we show on examples, how PoC flows can be adapted to
2.2 Performance Requirements radio network characteristics and to varying radio link conditions.
The performance design of the PoC application has to ensure that
E2E delay recommendations of the PoC standard [6] for time 3.1 PoC Signaling
critical message flows are met. The recommended delay values are
The PoC standard uses SIP based signaling for session control
shown in Table 1 below.
purposes [10]. Since SIP is a verbose protocol, its unmodified use
Table 1: PoC Release 1.0 End-to-end Delay Recommendations in radio access networks would either lead to unacceptable session
setup delays, or would increase the required radio link bandwidth
E2E Delay significantly. Table 2 shows the bandwidths needed by PoC sig-
PoC Message Flow
[s] naling flows in UL and DL directions for a given PoC user, if the
Session Set-up, Early media 2.0 PoC Release 1 delay recommendations are to be met.

Session Set-up, Early session 2.0 The delay values for PoC Session Set-up, Early media flows in the
Session 4th column of the table illustrate how signaling compression af-
Session Set-up, Late media 4.0 fects delay. The figures are results of detailed delay analysis of the
Control
Session Join-in 4.0 flow using measurements in a GPRS network with Siemens
BR7.0, GR 2.0 network elements.
Session Release 4.0
As it is seen from the table the requirement of using only one
Floor Request (Right-to-speak) 1.6 timeslot for PoC communications can be met if the SIP messages
Floor
Floor Release used in PoC session setups are SigComp compressed [4] with a
Control 0.8
(State Change Notification)
compression rate of about 70%. With this rate of SIP message
compression, the E2E delay recommended by Table 1 can also be
User Voice Transfer (One-way) 1.6 met. Since the RTCP messages used for floor control do not re-
Plane Immediate Response 4.0
quire much radio link capacity, their compression is not neces-
sary, nor suggested.
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 E2E Protocol,
measure, since it includes human reaction times in addition to the PoC Signaling Bandwidth
Direction Delay Compression
delays caused by Floor Release, Floor Request and by the subse- Flows [kbps]
[ms] Rate
quent Voice Transfer. All other metrics should be strictly main-
tained. In addition to the above delay requirements, the PoC de- 22.44 3.040 SIP, 0%
sign should ensure a voice quality that compares to the quality of
GSM circuit-switched (CS) voice calls. The PoC Release 1 stan- 11.22 2.012 SIP, 50%
Session Control UL/DL
dard [6] recommends a packet loss rate for voice frames 2% and
6.73 1.570 SIP, 70%
MOS 3 for voice quality perception.
4.49 1.340 SIP, 80%
3. PoC PERFORMANCE UL 0.28 n.a. RTCP, 0%
It is the task of performance engineering to identify those means Floor Control
for the PoC application and in the GPRS access network, which in DL 0.60 n.a. RTCP, 0%
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-

183
3.2 PoC Voice Media codec used and of the radio receive conditions (coding scheme
According to [6], PoC voice media is carried over the GPRS net- used) in the current radio cell of the PoC user.
work as a sequence of RTP [5] packets with constant bit rate, If we take, for example the default CS2 coding scheme among
where the voice payload is encoded with narrow band AMR codec typical radio link receive conditions, the number of voice samples
[3]. The RTP/UDP/IP headers of these IP packets represent a that can be packed in one IP packet is 5 n 17 using PoC de-
significant portion of the overall packet length. The overhead can fault AMR 5.15 codec. As a consequence, the one-way delay of
amount to a multiple of the voice payload if a low bit rate AMR voice transmissions will lie between 650 ms t 1520 ms.
codec is used. Without taking any measures to reduce this over-
head, the radio capacity consumption of PoC would be inhibiting If radio link conditions deteriorate and the use of CS1 encoding
high. Because of the half-duplex nature of voice communications becomes necessary over the radio link, the range of possible num-
in PoC a larger E2E delay is acceptable (refer to Table 1). This ber of voice samples reduces to 12 n 17. This will lead to a
makes the packaging of more than one voice frame into one IP higher one-way delay of about 1200 ms t 1520 ms if we use
packet possible and can help reduce the RTP/UDP/IP protocol the same AMR encoding. However, switching back to an AMR
overhead. Table 3 below shows some examples for radio link 4.75 codec, a smaller number of voice samples per IP packet be-
capacity usage that would be necessary to carry PoC voice over comes possible again (1 0 n 17) and the minimal E2E delay
GPRS in dependence of the AMR codec used and of the number can be reduced to 980 ms.
of voice samples packed in one IP packet.
In addition to the user plane adaptation strategy implemented by
Table 3: Radio Link Capacity Usage of IP Packets with Voice the PoC application, compression mechanisms can be applied to
Payload the IP flows if the underlying GPRS network supports them. The
impact of UDP/IP header compression [2] on bandwidth usage
# of Voice Samples per IP Packet, and E2E voice transfer delay can also be seen on the Figure. The
PoC Voice Bandwidth requirement [kbps] impact also depends on the number of voice samples per IP
Direction
Flow
packet.
1 2 4 8 10
Table 4: Efficiency Gain, UDP/IP Header Compression, Delay
RTP, AMR 4.75 UL/DL 25.6 15.4 10.3 7.8 7.2
# of Voice Samples per IP Packet,
RTP, AMR 5.15 UL/DL 26.0 15.8 10.7 8.2 7.6 UDP/IP
PoC Voice Media One-way Delay (R Gi) [ms]
RTP, AMR 12.2 UL/DL 34.2 23.8 18.6 16.0 15.4 HC
1 2 4 8 10
As it is seen from the table the requirement of using only one RTP, AMR 4.75 yes 253.9 254.5 335.7 458.0 499.1
timeslot for PoC communications can be met if low bit rate AMR
RTP, AMR 4.75 no 294.5 335.1 376.2 498.6 537.7
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). Efficiency gain [%] 13.8 24.0 10.8 8.1 7.5

Bandwidth requirement and Delay for PoC Voice Flow

AMR 4,75 AMRIF2,
1700,0 no header
1600 ms 25,00 compression

1500,0

AMR 4,75 AMRIF2,

with header
1300,0 20,00 compression
Round Trip Delay [ms]

18,6 kbps (CS4)

Bandwidth [kbps]

1100,0
AMR 5,15 AMRIF2,
no header
15,00 compression
900,0 13,4 kbps (CS3)

11,2 kbps (CS2) AMR 5,15 AMRIF2,

700,0 with header
10,00 compression

500,0 7,4 kbps (CS1)

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
The possible and useful range of adapting the transfer of IP pack- GPRS transport delay (between the R and Gi interfaces) for some
ets with voice payload can be seen on Figure 2. The Figure shows selected values. The efficiency gain is larger if a small number of
the limits of voice frame packaging in dependence of the AMR voice frames are packed into one IP packet. It decreases as the

184
number of voice frames per packet increases. Header compression load requires 7 radio blocks. The resulting one-way delay over the
also increases the efficiency of radio link capacity usage as seen Um interface (160 ms as seen on the Figure) can be calculated in a
on Table 5. GERAN under target load (i.e. without queuing delays in BTS
and BSC) as follows:
Table 5: Efficiency Gain, UDP/IP Header Compression, Band-
width msgLength n
n= t = 20ms + 20ms
# of Voice Samples per IP Packet blockSize timeslots
UDP/IP Bandwidth [kbps] The step-wise increase of the E2E delay in dependence of the
PoC Voice Media
HC
number of voice samples per IP packet in Figure 2 can also be
1 2 4 8 10 explained by the necessary number of radio blocks.
RTP, AMR 4.75 yes 16.8 11.0 8.1 6.6 6.4
3.4 GERAN TBF Establishment Delay
RTP, AMR 4.75 no 25.6 15.4 10.3 7.8 7.2
In the E2E delay analysis of PoC flows we have assumed that a
Efficiency gain [%] 34.4 28.6 21.4 15.4 11.1 radio channel with the necessary capacity is already available as
the IP packets begin to be transmitted. This is, however, not al-
Since the efficiency gain both in terms of radio link bandwidth ways the case in GPRS networks. A radio channel (with a Tempo-
(>11%) and in terms of GPRS transport delay (>8%) remains rary Block Flow TBF) is first established if an LLC frame with
significant even with several voice frames per IP packet, UDP/IP the first IP packet arrives for transmission. Thus, an additional
header compression should always be used if the mobile terminal delay for the establishment of a TBF has to be added to the pure
and the SGSN of the GPRS core support it. IP packet transport delays. Typical TBF establishment times in
GERAN are summarized Table 6. The rows in the Table represent
3.3 GPRS Transport Delay different circumstances in which radio channel establishments
A detailed analysis of the GPRS transport delay budget reveals may happen. It depends on the timing relationship between mes-
that a significant portion of the overall delay is contributed by the sages in a PoC flow, which of the TBF establishment delays oc-
thin wire of the radio link. curs.

GPRS Transport Delay of PoC Voice (AMR 4,75, 8 frames) Packet

180,0
TE 0,0
R-I/F
MT 10,0 160,0
Um
BTS 5,0
Abis 20,0
BSC 18,0
Gb 1,5
SGSN 17,8
Gn 0,2
Interface / Node

GGSN 0,6
Gi 0,0
B.B. 0,0
PoC 50,0
B.B. 0,0
Gi 0,0
GGSN 0,4
Gn 0,2
SGSN 18,5
Gb 1,9
BSC 29,0
Abis 20,0
BTS 5,0 160,0
Um
MT 10,0
R-I/F 0,0 180,0
TE
0,0 100,0 200,0 300,0 400,0 500,0 600,0 700,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 TBF Establishment Typical Delay
Circumstances
for 91.8% of the overall GPRS transport delay budget (R Gi) for Procedure [ms]
one-way (UL+DL) voice packet transmissions. The largest singu-
Channel is not yet active 300
lar delay component of the GERAN delay budget is the transport
delay over the Um interface. This is primarily due to the low Uplink TBF No concurrent DL TBF 250
bandwidth of the radio link that uses one GPRS timeslot with CS1 Concurrent DL TBF exists 150
encoding.
Channel is not yet active 230
The Um transport delay can easily be explained by the number of Downlink TBF No concurrent UL TBF 160
radio blocks that are necessary to carry the IP packet. The trans-
Concurrent UL TBF exists 100
mission of the header compressed IP packet with the given pay-

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

186
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 Proto-
col (SIP)
[5] IETF RFC 3550, RTP: A Transport Protocol for Real-Time
Applications
[6] Push-to-talk over Cellular (PoC), PoC Release 1.0, 08.2003,
Ericsson, Motorola, Nokia, Siemens
[7] 3GPP TS 21.102, 3rd Generation mobile system Release 4
specifications
[8] 3GPP TS 23.107, Quality of Service (QoS) Concept and
Architecture
[9] 3GPP TS 23.207, End-to-End QoS Concept and Architecture
(Release 5)
[10] 3GPP TS 24.229, IP Multimedia Call Control Protocol based
on SIP and SDP; (Release 5)
[11] 3GPP TS 26.071, Mandatory Speech Codec speech process-
ing functions; AMR Speech Codec; General description

187