Tài liệu Nhiều giao thức truy cập đối với truyền thông di động P11 docx

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

interface. One of the main benefits provided by IP technology is the service flexibility, as
already identified in Section 2.4. Another motivating factor for some operators is the wish
to focus exclusively on the packet-switched infrastructure, once the technology is ready,
to facilitate network management and possibly to save also on infrastructure costs. This
would imply that existing services, including ‘plain voice’, would have to be replicated
on the packet-switched infrastructure.
The top-level architecture devised by 3G.IP was adopted by 3GPP as a basis for
enhancements to the packet-switched part of the 3GPP network architecture which,
if further delays can be avoided, are to be incorporated in release 5 of the 3GPP
392
11 TOWARDS ‘ALL IP’ AND SOME CONCLUDING REMARKS
R
G
n
U
u
U
m
MGW
TE MT
EIR
R
TE MT
Applications
& services
Legacy mobile
signalling
network
Multimedia
IP networks

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

n
G
f
G
i
G
i
M
c
G
c
I
u
-PS
GERAN
UTRAN
MRF
MGCF
GGSN
SGSN
HSS
(HLR)
Figure 11.1 Simplified architecture for the support of IP-based multimedia services in 3GPP
release 5
specifications. A few new functional entities are to be introduced, which form the IP
Multimedia Subsystem (IMS), as shown in Figure 11.1. These are the Call State Control
Function (CSCF), the Media GateWay (MGW), the Media Gateway Control Function
(MGCF), the Media Resource Function (MRF), and Signalling GateWays (SGW).
Additionally, the PS-domain core network of UMTS release 1999 composed of SGSNs
and GGSNs (in itself an evolution from GPRS) has to be evolved to provide the necessary

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

have a relatively moderate impact on UTRAN. In terms of support of real-time packet
traffic over the air interface, the capabilities of the two UTRA modes, in particular the
UTRA FDD mode, were discussed in some detail in Chapter 10 and it was shown that
UTRA FDD provides considerable flexibility in this respect. One key concern relates to
spectrum efficiency, mainly due to the overhead introduced by IP and higher layer headers,
which has to be reduced or eliminated through appropriate means, as will be discussed in
Section 11.2. Other than that, further improvements on top of what is available in release
1999 are being considered and may be introduced, if proven beneficial. These include
both mechanisms to improve the radio link performance in general, and mechanisms
specifically targeted for optimised wireless IP support, in particular bi-directional real-time
and interactive IP-based applications. The latter could for instance consist of improved
common downlink channels.
For the so-called GSM/EDGE RAN (GERAN), as the GSM radio network infrastructure
is referred to from release 4 onwards, the situation looks different. Connecting GERAN
infrastructure directly to the UMTS core network, as intended, means that I
u
-CS and
I
u
-PS interfaces must be supported instead of the A and the G
b
interface. According to
Reference [296], the connection to the CS-domain via the I
u
-CS interface is not so much
different from that via the A interface. However, when comparing G
b
to I
u
-PS, which

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.

11.2 Challenges of Voice over IP over Radio
The Internet is working according to the end-to-end principle. It means that only the packet
source and the packet destination have to be interested in the packet contents, while the
network in between these two entities is assumed to be dumb. It does just one thing,
namely sending packets from one place to another, in theory without discrimination. It is
assumed that all packets are treated equally, and that their content is not tampered with.
This is exactly how the often-quoted service flexibility is achieved: since no assumptions
are made about the packets travelling across the network, there are no constraints on
the uses to which they can be put. In practise, as multimedia traffic containing real-time
streams is starting to be delivered over the Internet, means to provide appropriate QoS
forthesereal-timestreamshavetobeintroduced. This implies often that packets are not
treated equally anymore, but rather depending on the QoS requirements of the stream
they belong to.
Regardless of QoS matters, the end-to-end principle is in direct conflict with what the
cellular industry normally does, namely trying to optimise the use of precious spectrum
resources depending on the nature of the data to be delivered. We have discussed this in
detail for GSM voice in Chapter 4, where the importance of every single bit is known
and it is treated accordingly. Efficiency is derived from the following means:
• low-bit-rate voice codecs optimised for wireless use, ideally adapting to the channel
conditions;
• avoidance of header overheads since the application carried is known;
• Unequal Error Protection (UEP) according to the importance of the payload bits, so
that FEC coding redundancy is only expended for bits for which it is worthwhile;
• Unequal Error Detection (UED) so that the frame erasure rate (FER) depends only
on the residual error-rate of the most important bits (when used together with UEP,
typically the same bits that enjoy the strongest error protection).
The same is not true for circuit-switched data in 2G systems, however, where, with
the possible exception of payload compression (as an equivalent to low-bit-rate coding),
none of these techniques is applied, nor is it for packet-switched data in 2.5G systems.
So what are the concerns when dealing with real-time IP services?

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

the end-to-end principle is anyway apriori abandoned and the network should know what
its bearers are used for.
Knowing the importance of the bits and being able to apply UED and UEP accordingly
is only one important technique to improve the radio link performance, adapting the type
of voice coding depending on the current radio conditions is another one gaining impor-
tance. For instance, with the recently standardised Adaptive Multi-Rate (AMR) codec,
it is possible to trade off robustness against ‘voice fidelity’ depending on the current
radio conditions. If they are bad, it is better to choose a lower rate, allowing more FEC
redundancy to be added while keeping the channel rate constant, so that, even though
fidelity is reduced, intelligibility can be improved. This requires either local control of
the codec mode (e.g. by performing transcoding close to the radio link, that is converting
a radio-independent non-AMR bit-stream into an AMR-coded stream according to the
local conditions) or suitable end-to-end protocols to negotiate the rates. In the context
of VoIP, the former is clearly not in tune with the end-to-end principle. The latter raises
some challenges in terms of protocol architecture and information exchange. It would
still leave the end terminals in charge of how they want to deal with media streams, so it
could be considered end-to-end, but it would introduce dependence between the transport
infrastructure and the applications running on top of it. It would therefore affect service
flexibility.
396
11 TOWARDS ‘ALL IP’ AND SOME CONCLUDING REMARKS
11.2.2 VoIP Header Overhead
Real-time interactive traffic is often carried over IP using the Real Time Protocol (RTP)
as an application protocol and the User Datagram Protocol (UDP) as a transport protocol.
The header overhead specific to VoIP is therefore composed of IP, UDP and RTP headers.
UDP headers are 8 octets long, RTP headers at least 12, and the length of the IP headers
depends on the IP version applied. IPv4 headers are at least 20, IPv6 headers at least
40 octets long. Taken together, this means 40 octets or more with IPv4, and 60 octets
or more with IPv6. Additional overhead results, for instance, if IP voice packets are
encapsulated in an ‘outer’ IP packet, due for instance to the application of the mobile IP

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

compression, hence in the absence of transmission errors over the air interface, from
an IP perspective, this process works as if no header compression were applied at all.
Owing to the fact that these headers contain a lot of fields, which remain static over the
11.2 CHALLENGES OF VOICE OVER IP OVER RADIO
397
RTP
Air interface
Voice sample
Compressed
IP/UDP/RTP
header
Voice over IP over GPRS/UMTS
Network
Header compression and
decompression
Application generating/receiving
VoIP packets (e.g. SIP client)
MS decompression
entity (e.g. PDCP)
Compression at
RNC or BSC
RTP
(Remote
End Point)
IP UDP RTP Voice sample
Figure 11.2 Header compression over the air interface
duration of a voice call (e.g. the source and destination IP addresses), or change in a
predictable fashion (sequence numbers, RTP time stamps), very high compression ratios
can be achieved.
‘Early schemes’ suitable for IP/UDP/RTP header compression, such as that specified

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