Multiple Access Protocols for Mobile Communications: GPRS, UMTS and Beyond
Alex Brand, Hamid Aghvami
Copyright

2002 John Wiley & Sons Ltd
ISBNs: 0-471-49877-7 (Hardback); 0-470-84622-4 (Electronic)
11
TOWARDS ‘ALL IP’ AND SOME
CONCLUDING REMARKS
This concluding chapter provides first an introduction to some of the planned release 5
enhancements to UMTS and the GPRS/EDGE RAN (GERAN). These can be seen as the
first step towards ‘all IP’. The challenges when having to deliver real-time IP services
over an air interface, in particular voice over IP services, are summarised and possible
solutions to achieve spectrum efficiencies similar to those of optimised cellular voice
services are outlined.
Unlike the UTRA modes, the GSM/GPRS air interface was not designed to handle
real-time packet-data traffic. Further enhancements are required to support real-time IP
bearers in GERAN. Possible alternatives are discussed and planned solutions are briefly
described.
The last section provides summarising comments on multiplexing efficiency and access
control, two key topics that kept reappearing throughout this book, for TDMA, hybrid
CDMA/TDMA and CDMA systems.
11.1 Towards ‘All IP’: UMTS and
GPRS/GERAN Release 5
In early 1999, a few operators and infrastructure manufacturers got together to form
3G.IP [92], an ‘industrial lobby group’ intended to influence 3GPP (for UMTS) and
ETSI (for EDGE/GPRS) towards adoption of what was then termed an ‘all IP’ network
architecture. This further evolved GPRS architecture, based on packet technologies and
IP telephony, would function as a common core network to access networks based on
both EDGE and WCDMA radio access technologies. The system would have to be able
to deliver IP-based multimedia services efficiently, requiring also enhancements to the air

PSTN/
legacy/external
GGSN
SGSN
Signalling interface
Signalling and data transfer interface
Other PLMN
SGW
CSCF
M
m
M
h
M
s
C
x
G
i
M
r
M
g
G
i
G
r
G
p
G

quality of service for real-time traffic. Finally, the concept of the HLR has evolved, it is
to be substituted by a Home Subscriber Server (HSS).
One of the key components to provide IP-based multimedia services is the CSCF, which
executes, among other things, the call control. To be precise, it was decided to base the
required protocol on the IETF Session Initiation Protocol (SIP) [293]. ‘Session’ is in fact
a more generic and appropriate term than ‘call’. The latter is mostly associated with voice
calls, while the aim is to provide all imaginable types of IP-based multimedia services,
which may, but do not have to contain voice streams. A media gateway is required when
providing an interconnection from the GGSN to legacy circuit-switched networks, such
as the Public Switched Telephone Network (PSTN). The MGCF controls that gateway.
The MRF performs multiparty call and multimedia conferencing functions. The signalling
gateways perform signalling conversion as required.
Compared to the original 3G.IP reference architecture to be found in Reference [92],
for the 3GPP network architecture shown in the release 5 version of TS 23.002 [294],
some of the new elements were further decomposed. In particular, there are now different
types of CSCF, for instance a proxy CSCF with a policy control function, the latter
11.1 TOWARDS ‘ALL IP’: UMTS AND GPRS/GERAN RELEASE 5
393
having a separate interface to the GGSN, namely G
o
, on top of the G
i
interface shown
in Figure 11.1. Two types of signalling gateways were introduced, namely the Transport
Signalling GateWay function (T-SGW) and the Roaming Signalling GateWay function (R-
SGW). For details on the functionality of the individual components, see TS 23.002 [294]
and TS 23.228 [295]. To provide a simple picture, Figure 11.1 shows the original 3G.IP
reference architecture with a single type of CSCF and a single type of SGW, but with
some of the terminology adapted to that now used in 3GPP.
The introduction of the IMS and the evolution of the PS-domain of the core network

are the interfaces of relevance here, there are substantial differences. This has to do with
the functional split between the core network and the radio access network, which are not
the same in GSM and UMTS. It was decided to eliminate any radio-related functionality
from the UMTS core network, so that different types of radio technologies could be
connected to it (which is exactly what is happening here with UTRA and EGPRS). This
resulted in functionality located in the GPRS core network in R97 (and also in EGPRS
R99) to be pushed down to the RAN for UMTS R99. For instance, ciphering for the
radio link, which used to be performed by the SGSN in GPRS R97, is performed by the
RNC in UMTS. Accordingly, if a GERAN is to be connected via I
u
-PS to a 3G SGSN,
then the ciphering must be implemented in the GERAN. In terms of protocol stacks,
LLC and SNDCP known from GPRS terminate in the core network, whereas in UMTS,
where LLC and SNDCP were eliminated and PDCP introduced instead, the respective
functionality is contained in the RAN. The reader is referred to Reference [296] for further
information.
Another fundamental matter is that of the support of real-time packet traffic over the
air interface. Essentially, neither GPRS R97 nor EGPRS R99 provide means to support
real-time traffic over the air interface, so enhancements are necessary. Options and likely
solutions will be discussed in more detail in Section 11.3, after having outlined some of
the general challenges relating to the efficient support of voice over IP over air interfaces
in Section 11.2. These are relevant for both UTRA and (E)GPRS.
394
11 TOWARDS ‘ALL IP’ AND SOME CONCLUDING REMARKS
To conclude this section, we would like to point out that ‘all IP’ means different
things to different people. Evolving the GPRS core network, which makes use of some IP
technologies, and adopting a few IETF protocols such as SIP for session control, while
still keeping for instance cellular mobility management principles, is for a lot of people
far from ‘all IP’. For these people, release 5 provides only a first step towards ‘all IP’.
Possible evolutionary paths to ‘real all IP’ were briefly discussed in Section 2.5.

Let us consider what is probably the most challenging service from an efficiency
perspective, namely Voice over IP (VoIP). Assuming that it is desirable to carry voice
over the PS-domain, then VoIP is the most obvious way in which this could be achieved.
If a pure ‘plain’ voice service is to be offered (e.g. because it is required to replicate all
11.2 CHALLENGES OF VOICE OVER IP OVER RADIO
395
current services on the packet-switched infrastructure), then this service has to compete
against optimised circuit-switched voice in terms of efficiency.
There are two main reasons for which, without taking special measures, a VoIP service
cannot compete, in terms of spectrum efficiency, with optimised circuit-switched voice:
• lacking payload optimisation, i.e. having to use equal error detection and protec-
tion (EED and EEP) instead of UED and UEP, if the end-to-end principle is respected
(since the latter implies that there is no guarantee for the network to know the payload);
• the header overhead due to IP and higher layer headers.
It is important to note that these two factors are independent from whether voice is
carried on dedicated or shared channels over the air interface. Choosing circuit-switched
voice as a benchmark is simply due to the fact that this is the type of voice service which
is typically supported in cellular communication systems, and which allows a high degree
of optimisation. The same type of optimisation could also be performed if shared channels
were used on the air interface, using for instance PRMA as a multiple access protocol.
11.2.1 Payload Optimisation
As regards UED and UEP, if the payload is known (e.g. both the type of codec applied and
the ordering of the output bits according to their importance), these techniques can also
be applied in conjunction with a VoIP service. According to Reference [86, p. 96], UEP
performs around 1 dB better than EEP, in the conditions considered in Reference [297],
the performance difference is 1.5 dB. Using UED and UEP violates somewhat the end-to-
end principle, in so far as assumptions are made about the terminal behaviour and as the
terminals would have to let the network know what they are doing on the bearers they are
assigned. If a network-controlled ‘plain voice service’ is replicated on the packet-switched
infrastructure, with exactly the same features as the original circuit-switched service, then

protocol [96] or the IP security protocol with encapsulating security payload [298].
The IP-related header overhead is particularly disturbing with low-bit-rate real-time
services such as voice. Because of the packetisation delay, only a limited number of
voice frames can be packed into an IP datagram or packet. Ideally, to provide a decent
quality and keep the delay low, given a voice frame length of 20 ms typical for cellular
communications, there should be a one-to-one relationship between voice frames and IP
packets. Recall from Section 4.3 that a GSM full-rate voice frame lasting 20 ms measures
260 bits, hence roughly 33 octets before error coding, an enhanced full-rate frame 244
bits or 31 octets. In other words, with one frame per packet, the header overhead is
bigger than the payload, and this even before adding lower-layer headers (e.g. at RLC
and MAC), which are not required in an optimised voice solution, but may be required
for VoIP.
Given that spectrum is the most precious resource for an operator of a mobile commu-
nications system, the key concern is inefficiency on the air interface. Hence the question
is whether we do need to carry the headers over the air interface and, if we do, whether
we can somehow compress them.
11.2.3 How to Reduce the Header Overhead
11.2.3.1 Header Removal
Clearly, the most drastic approach to remove the IP-related header overhead is to terminate
the VoIP session in the RAN, i.e. at the BSC or the RNC, and to send conventional voice
without any headers to the mobile terminal. This would imply that there is no VoIP client
in the mobile terminal and the aspect of IP service flexibility would not be exploited.
However, it would still allow reliance on the packet-switched core-network infrastructure
for the delivery of the voice service.
11.2.3.2 Transparent Header Compression
The only approach that is compatible with the end-to-end principle and does not reduce
service flexibility, is so-called transparent header compression. It means that IP/UDP/RTP
headers are compressed, before a packet is sent over the air interface, and decompressed
at the receiving end, before being handed over to the IP stack (e.g. in the terminal).
This is shown in Figure 11.2 for the downlink direction. Transparency implies lossless

in Reference [299], were not designed for radio links and are known not to be suitable
for cellular communications [222,300]. Triggered by 3G.IP activities, a working group
was set up in IETF to deal with so-called robust header compression schemes, which are
at the same time very efficient and do not suffer unduly from errors experienced on the
wireless transmission medium. This RObust Header Compression (ROHC) scheme was
recently finalised and is specified in Reference [222]. It is supported by the UMTS PDCP
protocol from release 4 onwards [301]. A short description of a preliminary scheme,
which was fed into the ROHC standardisation process, can be found in Reference [302].
With ROHC, the average combined IP/UDP/RTP header size can be reduced to less than
two octets for a conventional two-party voice call, hence the relative header overhead is
reduced to a few percent, which appears to be acceptable. However, lossless compression
comes at the price of variable sizes for the compressed headers, as unexpected or rare
changes of certain header fields require longer compressed headers to be used. In the case
of UTRA FDD, for example, owing to the inherent statistical multiplexing capability and
the support of real-time VBR traffic, this can be tolerated (although it may, depending
on the solution adopted, consume precious TFCI code points to signal what header size
is currently being used). On the other hand, when trying to support packet-voice over the
rather narrow-band GSM carriers, which are partitioned into even narrower basic physical
channels, variable size headers are uncalled for.
Another problem in the end-to-end context is that the header compression entity can
only guess what media streams are carried by the IP packets it is dealing with, through
application of appropriate heuristics. To maximise the compression efficiency, it would
be helpful to separate a voice stream running over IP/UDP/RTP from other IP/UDP/RTP
streams to apply individually optimised ROHC profiles, and also from non-IP/UDP/RTP