<<

. 46
( 132 .)



>>

router in a format which it can understand.
As a solution to IP addressing constraints and the problems of host con¬guration NAT
is very effective. An operator working with one class C network address using dynamic
NAT translation can easily support over 16 million IP hosts. One critical limiting factor
will be the processing power of the NAT service doing the address translation, particu-
larly if the device where the service is located has a number of other tasks to perform,
for example the GGSN or ¬rewall. Another problem is the support for UDP within
NAT. Since UDP is connectionless the NAT service does not have any session infor-
mation to tell it when to delete a translation entry. In the case of UDP some sort of
timeout mechanism is generally used to determine when translations are idle and can be
removed.



5.7 IP-BASED QoS FOR UMTS NETWORKS
To provide a UMTS packet user with QoS, this must be an end-to-end consideration and
must therefore cover the Uu air interface, the Iub/Iu-PS connection through the UTRAN,
and the packet core IP backbone Gn interface. For each interface QoS must be provided
and possibly negotiated. Essentially QoS must be provided in three domains: air, radio
access and core network. For the air and radio access domains the RNC is responsible for
managing the QoS. For the PS core network the QoS is negotiated between the SGSN
and GGSN and is provided over the IP backbone. For the CS core network from R4, QoS
must be provided on the new packet switched core between the incoming and outgoing
media gateways (see Chapter 8). The core network and the UTRAN network for R5 and
beyond are both IP based and will use technologies such as DiffServ, integrated services
(IntServ) and resource reservation protocol (RSVP) to deliver QoS. For the UTRAN prior
to R5, the transport is based on AAL2, and ATM protocols will be used to negotiate QoS
for the radio access bearers.


5.7.1 QoS negotiation in UMTS
The basic operation of the QoS negotiation process for a GPRS service within UMTS
is illustrated in Figure 5.36. Initially the UE makes a request to the SGSN for GPRS
service (PDP context request) with a given QoS. In the example the request is for a
streaming service class with a data rate of 192 kbps. This request is passed to SGSN
transparently using radio resource control (RRC) and RANAP direct transfer messages.
Next the SGSN determines that it can provide the requested QoS and then sends a create
PDP context request to the GGSN. The GGSN at this point downgrades the QoS request
from 192 kbps to 128 kbps due to lack of bandwidth available on its connected network
and replies to the SGSN with a create PDP context response containing the adjusted QoS.
214 IP APPLICATIONS FOR GPRS/UMTS



UE RNC SGSN GGSN

Activate PDP Context Request
QoS Parameters:
Create PDP Context Request
data rate = 192kbps
QoS Parameters:
traffic class = streaming
data rate = 192kbps
traffic class = streaming
Create PDP Context Response
QoS Parameters:
RAB Assignment Request
data rate = 128kbps
bit rate = 64kbps
traffic class = streaming
traffic class = streaming
RRC Radio Bearer Setup
RAB Assignment Response
bit rate = 64kbps
traffic class = streaming
Activate PDP Context Accept
QoS Parameters:
data rate = 64bps
traffic class = streaming


Figure 5.36 QoS negotiation in GPRS (R99)

At this point QoS has been negotiated for the backbone and the GGSN connection to the
¬nal destination. However, it is the SGSN that is responsible for the packet switched core
network QoS, and, based on its available resources, as shown in Figure 5.36, it makes a
decision to further downgrade the bandwidth allocation to 64 kbps.
To transfer data between the SGSN and the UE a radio access bearer (RAB) must be
provided. The SGSN sends a RAB assignment request to the RNC. The RNC will deter-
mine if it has enough resources available over the Uu interface and within the UTRAN
(i.e. over the Iub and Iu interfaces) to ful¬l the request. It does this through its radio
resource management procedures of load control and packet scheduling. If so, it instructs
the base transceiver station (BTS) using the node B application part (NBAP) to recon¬g-
ure the radio link to support this new bearer and then sends a radio bearer setup message
to the UE via its existing signalling connection, as discussed in Chapter 6. The UE con-
¬rms to the RNC that it has received allocation for the new bearer (radio bearer setup
complete), and the RNC then con¬rms the RAB assignment to the SGSN (RAB assign-
ment response). Now the SGSN replies back to the UE that the PDP context has been
activated with the new data rate of 64 kbps.
All the way along in this process each element responsible for controlling a different
part of network resources can renegotiate the QoS parameters. If the RNC for example
does not have enough radio frequency (RF) resources within the target cell to provide the
requested data rate then it is free to renegotiate the QoS downwards.



5.7.2 GPRS QoS parameters
Table 5.11 shows the QoS attributes that can be negotiated for a GPRS link over UMTS
(see 3GPP TS24.008 and TS23.107). In practice, many of the QoS parameters are not
5.8 QOS FOR THE GPRS CORE NETWORK 215


Table 5.11 UMTS QoS parameters
Parameter Description
Traf¬c class Options: conversational, streaming, interactive,
background
Delivery order Options: ensure order, don™t ensure order
Delivery of erroneous service Options: do not detect, deliver them, don™t deliver them
data unit (SDU)
Maximum SDU size Range from 10 to 1520 bytes
Maximum bit rate for uplink Range 0“8640 kbps
Maximum bit rate for downlink Range 0“8640 kbps
Bit error ratio range 5 — 10’2 “6 — 10’8
Residual bit error rate (BER)
SDU error ratio range 1 — 10’2 ’ 1 — 10’1
SDU error ratio
Transfer delay Delay in range 10“4000 ms only for streaming and
conversational class
Traf¬c handling priority 1“3 (only relevant for interactive class)
Guaranteed bit rate uplink Range 0“8640 kbps (streaming and conversational)
Guaranteed bit rate downlink Range 0“8640 kbps (streaming and conversational)


negotiated, but are taken directly from those assigned in the user™s pro¬le, which is part
of their service agreement. For example, a user may have opted for a budget package,
where a connection to the packet core is only permitted to be a maximum of 64 kbps. In
this case, the PDP context activation request will show ˜subscribed™ for these parameters.
For GPRS/GSM (R97/98) networks a range of QoS attributes, including classes for
delay, reliability and precedence as well as maximum and average throughput, were
de¬ned. The QoS speci¬cations available for UMTS provide a higher degree of control.
TS23.107 has recommendations on how to map the R97/98 attributes to the R99 attributes
in case of inter-system handover.



5.8 QOS FOR THE GPRS CORE NETWORK
Networks are less capable of providing QoS as they become more highly loaded but the
provision of a lightly loaded network will not always guarantee good QoS to the user.
If the traf¬c is assumed to follow the Poisson distribution then one can apply queuing
theory. For a normalized traf¬c rate of A Erlangs the chance of the router having N
frames waiting to be transmitted is:

P (N ) = (1 ’ A) — AN

An Erlang is a normalized expression of traf¬c and is calculated as follows for a packet
switch domain:
Arrival rate in packets per second
Traf¬c in Erlangs =
Service time for packet
216 IP APPLICATIONS FOR GPRS/UMTS


It is also directly convertible from the network percentage load:
Load (%)
Erlang rate =
100
For a traf¬c load of only 10% or 0.1 Erlangs the probability of ¬ve frames being
queued at the router at any given time would be 0.000009. This percentage seems small
but if the router is receiving and transmitting frames each of 1500 bytes in length down a
gigabit link then it will receive 83 333 frames (1 — 109 / (1500 — 8)) a second. The average
number of these frames that will ¬nd the routing queue contains ¬ve packets will be 0.75
(83 333 — 0.000009), therefore the condition will occur 2700 times in a one-hour period.
Since the traf¬c is serviced at the router quickly this may not be a problem since the
delay involved in forwarding ¬ve 1500-byte packets will be only:
5 — 1500 — 8/1 000 000 000 = 0.00006 s or 60 µs
If the incoming buffer to the router does not store more than ¬ve frames then the next
incoming frame could be lost and may require retransmission. In this case the increase
in delay can be considerable since the packet will have to be transferred over the slower
UTRAN network.
Notice that the formula for the probability is unbounded by the queue length, i.e. there
is a chance (albeit a small one) that there will be any number of packets queued at the
router at any given time:
(1 ’ A) — AN is non-zero for any value of N as long as 0 < A < 1
There is another important formula that can be used to help predict the behaviour
of network switching components, which gives the average length of the queue at a
given router:
L = A/(1 ’ A)
As the value of A approaches 1 the network becomes saturated and the average queue
length (L) moves to in¬nity. It is prudent to check the average queue length against the
buffering capability of the router; if the network is at a high load and the buffer over¬‚ows
then packets will be lost and the network is deemed to be congested.
Another issue with QoS is the effect that low priority data traf¬c (e.g. email) can have
on the traf¬c which has tighter QoS requirements (e.g. packetized voice). This is best
illustrated by an example. Consider a router has started to forward a 1500-byte email
packet over a 64 kbps link. A newly arrived voice packet would be delayed for:
1500 — 8/64 000 = 0.1875 or 187.5 ms
This is regardless of the allocation of bandwidth for the email. The solution in this case
is to fragment the data packets before they are forwarded on the link.
It can be seen that controlling average traf¬c load is a necessary but not always suf¬cient
condition for providing QoS. Apart from total load control, QoS techniques may include
the following:

• individual ¬‚ow control (limiting ¬‚ow data rate);
• shaping the traf¬c (e.g. limit on maximum burst size over a given time);
5.8 QOS FOR THE GPRS CORE NETWORK 217


• reserving resources such as bandwidth or buffer space at routers or hosts for a given
¬‚ow;
• handling different traf¬c ¬‚ows with different priorities;
• breaking long packets up to avoid head-of-line blocking.

The next section examines two types of service that can be used to provide QoS in the
GPRS core network, DiffServ and IntServ. In fact with R4 and R5 these techniques can
be extended into the UTRAN and circuit switched domain as the whole of the UMTS
transport evolves to an all-IP architecture.


5.8.1 Differentiated services (DiffServ)
DiffServ (RFC 2474) works by separating traf¬c into classes and provides an appropriate
treatment for each class. For example all voice traf¬c might be run in one class and be
given a higher priority than another class of packets, such as those containing email data.
DiffServ makes use of the 8-bit type of service (TOS) ¬eld in the IP header (Figure 5.37),
which is referred to as the differentiated services (DS) byte. Use of the TOS ¬eld will
not in general affect how the ¬eld has historically been used. In particular, the three
precedence bits (used for priority) which are used by IP will still maintain their function.
However, no attempt is made to ensure backwards compatibility with the traf¬c control
bits (DTR, i.e. delay (D), throughput (T) and reliability (R)) as de¬ned in RFCs 791
and 1349. Figure 5.37 illustrates how the original ToS ¬eld in the IP header is modi¬ed
by DiffServ.
DiffServ relies on boundary devices at the edge of the network (Figure 5.38) to pro-
vide an indication of the packet™s service requirements. These boundary devices need to
examine the packet and set the DS byte codepoint value. The DS byte codepoint value
speci¬es the per-hop forwarding behaviour (PHB). Within a GPRS core network the
boundary function could be hosted within the SGSN and GGSN.

New: Differentiated Services (DS) byte

0 1 2 3 4 5 6 7


Differentiated Services Code Currently
Point unused



Original: Type of Service (ToS) byte
0 1 2 3 4 5 6 7


Currently
Precedence D T R
unused



Figure 5.37 ToS to DS mapping
218 IP APPLICATIONS FOR GPRS/UMTS


DS boundary devices

DS Domain



DS Router
DS DS
DS Router
Ingress Egress
DS Router
on ingress, packet is
on egress, packet
DS Router
metered, marked, DS Router may be reshaped
shaped and policed


Routers share PHB group

<<

. 46
( 132 .)



>>