<<

. 44
( 132 .)



>>

e.g. Internet
Backbone
GGSN
SGSN
Uu Iu Packet Core

Figure 5.29 UMTS release 99


RNC SGSN
RNC SGSN RNC RANAP RANAP
User data User data User data User data SCCP SCCP
GTP GTP GTP GTP M3UA M3UA
UDP UDP UDP UDP SCTP SCTP

IP IP IP IP IP IP
AAL5 AAL5 L2 L2 AAL5 AAL5
Iu-PS Gn Iu-PS
ATM ATM L1 L1 ATM ATM

(a) (b)

Figure 5.30 IP transport user and control plane (R99)


the UTRAN is expected to use ATM at layers 1 and 2. In later releases this constraint is
removed as the network moves to an all-IP architecture independent of L2/L1 transport.
Figure 5.30(b) shows how IP may be used as transport for radio access network appli-
cation part (RANAP) signalling over the Iu packet switched interface, although ATM is
currently the most popular choice for this release. Since the signalling is a signalling
system no. 7 (SS7) SS7 application protocol it is usually transported using the message
transfer part (MTP) protocols (i.e. MTP3, MTP2 and MTP1). To carry SS7 over IP
(SS7/IP) two protocols were developed: SCTP and M3UA. The addressing schemes of
IP and SS7 are different (SS7 uses a three-level address called a point code instead of IP
addresses). The MTP3 user adaptation layer (M3UA) provides routing for SS7 messages
across an IP network. It provides translation between the SS7 codepoint addressing and
the IP address and allows the IP end point to be seen effectively as part of the SS7
network. Using this mechanism the SS7 user part protocols are not aware that they are
not running over MTP3 as is usual.
The streaming control transmission protocol (SCTP) is a replacement for TCP and
provides a service more suitable for SS7 messaging. SCTP provides extra reliability by
5.6 IP FOR GPRS AND UMTS R99 203


allowing multiple IP end points to be used for each end of the connection (fail safe
redundancy). It also provides protection against some denial of service attacks that TCP
can be vulnerable to. SCTP in terms of data service allows a number of streams to be
delivered independently across one SCTP association. It also allows individual packets
to be delivered out of order without having to wait for a single packet that was lost in
transit. This is useful for protocols such as SS7, which need the data to be delivered
expeditiously but also require a guaranteed service. The architecture for transporting SS7
over IP, commonly referred to as sigtran (signalling transport), is covered in more detail
in Chapter 8.



5.6.1 Reliability and virtual router redundancy
protocol (VRRP)
Even though IP network components have gained a reputation for reliability and robustness
they are not yet comparable to traditional circuit switch telephony based equipment (e.g.
PSTN exchange equipment) in terms of fail safe operation. To overcome these problems
a number of solutions have been used over the years, most of them based on system
redundancy. With this type of scheme parts of the hardware (and software) are duplicated
and if one part fails the others can take over. Examples of these are redundant power
supplies, disk RAID systems and backup links.
When operating IP in a carrier network environment it is essential to provide backup
for the routing components. If an access router on an internal network fails this can result
in the network being denied connectivity. Looking at Figure 5.31, it can be seen that the
failure of the GGSN will deny GRPS access to the Internet.
Traditionally, with IP, routing failure has been handled via the use of dynamic routing
protocols. These will re-route the packets if a router crashes or is taken out of service.
This works well with routers within the core of the network but it does pose a number
of dif¬culties with edge routers, for the following reasons:

• only one connection may be available to the outside network;
• commonly hosts are con¬gured to use a default gateway to the outside world; if that
gateway fails they must be recon¬gured to use a different gateway;
• it will take some time for the new route to be established (convergence time), depending
on the routing protocol;

UTRAN Packet Core


Data Network
IP
e.g. Internet
Backbone
UE SGSN GGSN
RNC
Uu WBTS Iu

Figure 5.31 GGSN single point of failure
204 IP APPLICATIONS FOR GPRS/UMTS


• many networks rely on the use of static routes when dealing with routes to other
domains and in this case dynamic re-routing is not available.

With SS7 networks, signalling transfer points (STPs) are arranged in what is called a
mated pair con¬guration in which each is connected to the same set of incoming and
outgoing components.
With IP networks a redundancy protocol has been proposed called virtual router redun-
dancy protocol (VRRP; RFC 2338). Using this mechanism a router can be backed up
with one or more alternative routers which will take over in the case of failure. When a
router takes over the functions of its companion it not only uses the same IP address but
also the same MAC address. This means that other components on the IP network can
continue working without knowing about the con¬guration change; even the ARP cache
within the other routers will still contain valid information.
VRRP is designed to provide backup extremely quickly so that network service is
disrupted only for a very short period of time.
The protocol operates as follows. Each physical router running VRRP can be con¬gured
to provide services for a number of virtual routers, which act as the default routers for
sets of hosts on the network. The virtual routers have a virtual router identi¬er (VRID)
and one or more IP addresses (and corresponding MAC addresses) to which they are
expected to respond. Within the physical router each virtual router is allocated a priority
from 0 to 255. A priority of 255 means that the physical router is expected in normal
operation to perform that virtual router™s routing function. A priority of less than 255
means that router will act as backup. By taking over ownership of a virtual router™s set
of IP and MAC addresses a router can act as a backup to a companion that has failed. To
keep each other up to date, each router advertises the current virtual routers it is master
of by sending VRRP packets to its neighbours. If a router fails to receive updates for a
given length of time from the master of a virtual router that it is backing up then it takes
over the role of master and starts advertising itself as the new master. An example of this
is illustrated in Figure 5.32.
Router A is con¬gured as the master of the virtual router with ID 1 and IP address
128.7.0.1 and backup for virtual router ID 2 with IP address 128.7.0.2 and a priority of
200. Router B™s con¬guration is the reverse (master of 2 and backup for 1), making them a
mated pair con¬guration. In normal operation, shown in Figure 5.32(a), each router sends
VRRP packets advertising the virtual routers it supports to multicast address 224.0.0.18
(VRRP allocated multicast). If router A crashes or is taken out of service router B will
detect it has a backup ID from which it has not seen VRRP packets for some time. After
a given timeout it will take over virtual router with ID 1 and start to advertise itself as
the master for 1. If some time later router A comes back online it can take over as master
of virtual ID 1 by just advertising itself as owner with a higher priority. Router B will
see that router A has higher priority and release ownership.
When con¬guring VRRP it is important to understand how the priorities will affect the
timeouts. Each router is expected to send VRRP packets determined by the advertisement
interval, the default value being 1 second. The time for a backup to take over the role of
a master when not seeing advertisements is:

((256 ’ backup priority)/256) + 3 — advertisement interval
a) Routers advertise VRIDs that they
are master of by sending VRRP packet
to multicast address 224.0.0.18




Virtual Virtual
IP address Priority IP address Priority
ID ID
5.6 IP FOR GPRS AND UMTS R99




Virtual ID 001 Virtual ID 002
001 128.7.0.1 255 002 128.7.0.2 255
IP address 128.7.0.1 IP address 128.7.0.2
Priority 255 Priority 255
002 128.7.0.2 200 001 128.7.0.1 200



Router A Router B
b) If router A fails router B becomes
Virtual ID 002
master of Virtual router ID 1 and
IP address 128.7.0.2
advertises it as well
Priority 255
Router B must now route for both
Virtual ID 001
addresses
IP address 128.7.0.1
Prority 200

Ethernet

Figure 5.32 VRRP operation
205
206 IP APPLICATIONS FOR GPRS/UMTS


So for the previous example with an advertising interval of 1 second this time will be:

(256 ’ 200) + 3 = 59 seconds

The shortest timeout available will be (255 ’ 254) + 3 = 4 advertisement intervals.
This means to achieve a backup time of less than 0.1 seconds the advertisement interval
would have to be 0.02 seconds or 50 times a second. There is evidently a tradeoff between
advertising frequently and generation of a considerable volume of network traf¬c for
fast response times against less network traf¬c with poorer response. It should also be
noted that the destination address of the VRRP packet is multicast and therefore will be
forwarded by bridges and switches across the LAN.
While not directly part of the speci¬cation, VRRP is recommended by the Third Gener-
ation Partnership Project (3GPP) for the backup of GGSN services within a GPRS/UMTS
network environment.


5.6.2 VRRP virtual MAC addresses
Since VRRP allows the router™s MAC address to be modi¬ed, there is an issue in terms
of what MAC address to use. Routers could in theory use the original MAC address of
their neighbour™s interface card. This, however, makes con¬guration complex since all
the original MAC addresses would have to be discovered and distributed between the
VRRP routers. In practice virtual MAC addresses are used instead, each with a 5-byte
pre¬x of 00-00-5E-00-01. The 00-00-5E is set aside for virtual addresses by the IEEE and
the 00“01 is especially for VRRP. The last byte of the MAC address is the virtual router
ID. This means that up to 255 VRRP routers can be supported on a single LAN segment.
For the example given previously, the MAC addresses would be 00-00-5E-00-01-01 and
00-00-5E-00-01-02.


5.6.3 IP header compression
When sending data over the air, optimal use of the available bandwidth is essential since
the obtainable data rate is somewhat limited. Also of note is the fact that when sending
packets of data containing interactive voice, since transmission delay increases with packet
size, shorter packets are preferred. The problem with short packets is that they tend to be
less ef¬cient because the overhead suffered due to ¬xed header components will increase
as the packet size shrinks. If D is the data length and H the header length, the overhead
percentage is 100 — H/(D + H). Hence, as D decreases the percentage overhead tends
towards 100%. For example, consider voice samples carried using the real-time transport
protocol (RTP) over UDP/IP. The total header length will be RTP (12) + UDP(8) +
IP(20) = 40 bytes. Since many voice schemes send data in 20-byte samples, then this
will result in an overhead of 40/60, or 66%, with only 33% of the bandwidth being
available for voice data.
To help overcome this problem, a number of schemes have been devised to compress
the IP and UDP header parts of the packets (and therefore reduce the size of H). All
compression schemes work on the principle of redundancy. The redundancy of a message
5.6 IP FOR GPRS AND UMTS R99 207


is that which can be removed and the message still reconstructed at the far end. For
example, if shown the sentence ˜The cat s t on the m™ an average reader would have
little problem ¬lling in the blanks even though the message has had some data removed.
Examining a stream of packets moving from one host to another and looking at the
contents of the headers, a great deal of similarity is seen from packet to packet. For
example, the IP source and destination address may not change often over a given length
of time, and ¬elds such as the initial header length (IHL) and version number will probably
never change for the whole of the transmission time.
Most header compression schemes work roughly as follows:

• never send the contents of ¬elds that are not changing;
• for those ¬elds that are changing, try to send only the change in the ¬eld and not the
whole ¬eld again.

At the beginning of transmission, the whole of the header is sent uncompressed over
the link and then subsequently, only the changes are sent. This is the basis for a popular
TCP/IP header compression scheme developed by Van Jacobson and described in RFC
1144. Van Jacobson noticed that for any given TCP connection, about half of the 40 bytes
of header information (TCP 20 + IP 20) does not change for the lifetime of the connection.
So instead of sending the data repeatedly, the uncompressed header is sent once and then
for subsequent packets, an 8-bit connection identi¬er is transmitted with the changing
¬elds. For the ¬elds that might change, a bit mask is sent indicating which ¬elds have
changed since the previous header was sent, and instead of sending the whole ¬elds again,
only incremental value are sent. This method is particularly relevant for sequence and
acknowledgement numbers, since these will only be incrementing.
In the case of a packet being lost on the link due to errors, then the TCP header of
new packets will be reconstructed incorrectly due to the loss of the compressed header.
This corruption of the packet header will cause the sequence number to be reconstructed
incorrectly and the receiver will discard the packet. When the sender times out the packet
will be sent again, the compressor will detect the duplicate sequence number and will
send an uncompressed header. At this point the sender and receiver will be back in sync
and the compression can proceed as normal.
IP header compression is used between the UE and the RNC, and the compression is
performed by the packet data convergence protocol (PDCP).


5.6.3.1 PDCP IP header compression
For PDCP R99 the compression scheme used is speci¬ed in RFC 2507. This provides

<<

. 44
( 132 .)



>>