. 45
( 132 .)


support and de¬nes compressed header formats for all of the following:

• IPv4 and IPv6 (including IPv6 extension headers)
• TCP and UDP transport options
• IP Security (IPSec) header, i.e. encapsulating security payload (ESP) and authentication
header (AH).

The compression uses a scheme loosely based around the Van Jacobson technique but
modi¬ed to allow it to cope with non-reliable protocols such as UDP. Each compressed
packet is sent pre¬xed with a context identi¬er (CID), which indicates the compression
context to be used at the decompressor. The context contains a full copy of the header of
the last packet received by the decompressor (or at the send side, the last packet header
compressed by the compressor). The compression is achieved by sending only differences
between this context and the next header to send. Packets are grouped into streams, where
a packet for a given stream will be compressed using a particular context. The grouping
of packets into streams is dependent on the headers present. For IPv4/UDP the packets
are grouped using source and destination IP address, source and destination UDP port
number, IP version, IHL and type of service.
Five types of packet are supported:

• Full header: packet with uncompressed header
• Compressed non-TCP: non-TCP packet with compressed header
• Compressed TCP: TCP packet with compressed header
• Compressed TCP non-delta: TCP packet but not using differential coding
• Context state: lists of CIDs for contexts needing repair.

The full header is sent when a new context is created or when the receiver™s context is
in need of repair (for example when a packet is lost). These headers have the same format
as a standard IP header except that they also contain the CID and generation ¬eld (for
non-TCP headers). To make sure that the length of the packet is not increased, the CID
and generation ¬eld are carried in the length ¬eld. The length ¬eld is then reconstructed
using the Layer 2 frame length information at the receiver.
The compressed non-TCP packet is made up of a CID, a generation ID and the header
¬elds that change from packet to packet. The format of the compressed non-TCP packet is
¬xed for a given set of headers. Figure 5.33 shows the format for a UDP/IPv4 compressed
header. The ¬gure shows an 8-bit CID. It is possible to use 16-bit CIDs by setting the
extension bit, X, to 1. In this case the generation ¬eld will be followed by the least
signi¬cant byte of the CID. The D bit allows for the addition of an optional data ¬eld. Its
use must be negotiated before the compression session begins. One possible application
is as a sequence number when compressing streams such as RTP.
The generation value is used to indicate the version of the context to use to decompress
the packet. It is incremented each time a full packet header is sent. If a packet is received
for a given context with an incorrect generation value, it cannot be compressed and must
be discarded, or saved until a full header establishes the correct context.

CID XD Generation IP fields UDP fields
8 bits 00 6 bits UDP Checksum

Figure 5.33 IPv4/UDP compressed header

The only header ¬elds that have to be sent are the IP fragment identi¬cation ¬eld
and the UDP checksum. All the other ¬elds are expected to be read from the context or
calculated when the packet is received (e.g. datagram length or IP header checksum).
The compressed TCP packet is similar to the RFC 1144 format. The ¬elds are only
sent if they have changed from the previous packet. Flags are used to indicate which
¬elds have changed since the last packet sent. Some of the ¬elds are sent as they are,
whereas others are sent as delta changes (i.e. the difference between this value and the
previous one). If a compressed TCP packet is lost, then all following compressed TCP
packets cannot be decompressed because the context will be invalid.
The compressed TCP non-delta packet contains a compressed TCP/IP header but all
the ¬elds that are usually sent as delta values are sent as is. The TCP header is sent in
this form when a repair of the context is required, for example when a compressed TCP
packet is lost.
Finally, the context state is sent to the sender to tell it which CIDs require refreshing.
The sender is expected to send full headers for all the packets. This allows for optimization
of the repair mechanism since the receiver does not have to wait for the TCP retransmit
timer to timeout before receiving the context update. Robust header compression
Because of the slow turnaround time and high error rates of wireless links, many packets
can be lost in the face of loss of context. To help overcome these problems, a complex
scheme called robust header compression (ROHC; RFC 3095) has been developed. This
scheme is offered as an enhancement over RFC 2507 for UMTS R4 and beyond.
This technique is similar to RFC 2507 but implements a more complex algorithm to
try to reconstruct a valid header in the face of errors. A cyclic redundancy check (CRC)
is also sent with each compressed header, which is valid for the uncompressed header.
If the header CRC fails when uncompressing the header, then the decompressor tries to
interpolate from previous headers the missing data and checks the result again using the
CRC (Figure 5.34). This process of trying to repair the decompressor™s context will be

Try different
No Counter
CRC correct?

Yes Yes
Give up

Forward Request
packet update

Figure 5.34 ROHC decompressor

tried a number of times and if this process fails the decompressor will ask for a context
update from the compressor, which will then send it enough information to ¬x the context.
ROHC uses a number of different message types between compressor and decompres-
sor. A static update message is sent at the beginning of a transmission and contains ¬elds
that are not expected to change throughout the lifetime of the packet stream (for example,
IP source and destination addresses). To identify each packet stream, an 8-bit CID is
used. Dynamic updates are used to update ¬eld addresses that are not covered in the
static update, and need to be sent in an uncompressed form. In general, dynamic updates
will be sent once at the start of the connection and then only if the ¬elds cannot be sent in
a compressed form. The ¬nal type is the compressed packet, which transfers the minimal
data required to update the decompressor context so that the header can be reconstructed.
Robust header compression is of such importance to wireless transmission schemes that
it has been assigned its own IETF working group. For more information please refer to

5.6.4 IP address depletion and GPRS
With the advent of GPRS and the fact that there are over 800 million mobile subscribers
globally there will be renewed pressure on the IPv4 limited address space. Currently a
large number of IP network addresses have already been allocated to the major ISPs,
leaving little space for future expansion. Eventually with the move to IPv6 this will cease
to be a problem but until then other solutions must be sought. Two solutions currently
already used by organizations providing connections for their intranet users to the Internet
are dynamic host con¬guration protocol (DHCP) and network address translation (NAT).

5.6.5 Dynamic host con¬guration protocol (DHCP)
Saving address space by using dynamic host con¬guration relies on the fact that not every
user will be using IP services at any given time. For example on a mobile network the
phone may be switched off or even if on may not be making a data call. The ISP or
operator starts with a pool of addresses. When a user requires to connect to the IP service
he or she is given an IP address temporarily from the pool. This is called a lease of the
address. This system works for as long as the number of users online at any one time
does not exceed the size of the pool. This is very much how a PABX supports many
phone users with only limited outside lines. The protocol that supports dynamic host
con¬guration is called DHCP and is used globally by ISPs to assign IP addresses to their
user base. DHCP also assigns other important addresses to the host such as the default
DNS server and default gateway. In fact, the great bene¬t for the ISP is that it relieves
them and their customers from the onerous task of having to manage the address space and
con¬gure each host manually. DHCP is the successor to another dynamic con¬guration
protocol, called bootstrap protocol (BOOTP). BOOTP also allocates an IP and gateway
address to a host but does not use the concept of a lease (the IP address is allocated for an
inde¬nite period). For this reason it is not suitable if IP address reuse is needed. DHCP is

used within GPRS to dynamically allocate an IP address to the mobile device once it has
requested a PDP context activation. It is used for any mobile devices that do not have a
static mapping de¬ned in the home location register (HLR) for a particular access point. If
a user is connecting to an external network such as the Internet, then the DHCP allocation
is performed within the GPRS IP backbone. The DHCP service normally resides within
the GGSN. This allocation method is referred to as transparent mode. If, however, the
user is connecting to their corporate intranet, the IP address may be allocated from within
that network. This is known as non-transparent mode.

5.6.6 Network address translation (NAT)
DHCP works well at assigning a limited pool of addresses to a number of users but does
nothing to expand the total address space available. A network operator working with a
class C network address would only be able to support a maximum of 254 IP addresses.
Some system clearly needs to be introduced to allow a larger number of hosts to connect
to the Internet, without the requirement for large numbers of public IP addresses. This is
particularly the case with GPRS/UMTS, where the network is often expected to support
many millions of users simultaneously. As was seen earlier, there are a range of addresses
set aside for internal use, as shown in Table 5.10.
The addresses in Table 5.10 can be used internally within the operator™s private network
as long as they are not seen by any external hosts on the Internet. Any user that needs
to connect directly to the Internet must have a public address so that IP packets can be
correctly routed back to the user. However, consider that the operator has a class C address
available. This clearly will not support the number of subscribers that could potentially
be connecting to the Internet simultaneously.
To solve this dilemma, the operator will allocate private internal IP addresses to users
when they establish their PDP context, usually using DHCP. When a user connects to
the Internet, network address translation (NAT) performs the necessary translation to an
external IP address.
In the simplest form of NAT, referred to as static translation, there is a ¬xed mapping
between an internal IP address and the public IP address. This is typically used for devices
such as a publicly accessed server (e.g. a WAP gateway), which needs to be able to accept
connections from an external source.
Static translation is well suited for use with servers that are permanently situated and
accepting connections. However, it does not provide ¬‚exibility for users who are being
dynamically allocated an IP address on demand when they connect. For this general
situation, dynamic translation is where many internal users who have their own private

Table 5.10 Reusable private addresses
Class Addresses


IP addresses share the external address. In this case, to ensure that the correct translation
takes place, the different internal IP addresses are mapped to different port numbers in
the router. This NAT translation often resides in the GGSN, but may be situated in a
separate unit, possibly incorporated into the ¬rewall. Dynamic translation is sometimes
referred to as NAPT (network address and port translation) but more commonly as simply
NAT. Recall that a TCP or UDP packet has a 16-bit number for the port value, which
allows 216 = 65 536 unique ports per IP address. Those below 1024 are referred to as
well-known ports and are used for speci¬c services. However, many of those ports above
this range are available for NAT. It is therefore possible to have a large number of TCP/IP
connections and thus many internal devices sharing a single external IP address.
Consider the example con¬guration shown in Figure 5.35. Here, the operator is using
the class A private address internally and has a public class C address
and the UE is allocated the IP address by DHCP. The user connects to the
external web server, where port 80 identi¬es the HTTP service. The
request from the UE uses its allocated IP address and port number 1345.
At the NAT service, the internal request is translated to an external class C address with port number 16456. It is to this address and port number that the web
server replies, and again the NAT service translates the destination IP address back to the
internal address and port number 1345.
The port mapping entry can be made in the lookup table once the TCP connection is
established, and then deleted at the end of the TCP transaction. There is another form of
NAT, referred to as load balancing translation, where a router can spread the connections
of a very busy server to a number of identical servers, each of which will have its own

Translation Table
Internal External
... ...
Packet Core

UTRAN Internet
UE Web Server
NAT Service
DHCP: Allocate private IP address

Web Server Request
Translated Web Server Request
Web Server Response
Translated Web Server Response
From: To:

Figure 5.35 NAT address translation

unique IP address. This scenario is often the case for access to a busy web server on the
Internet. The router will check to see which of the servers is the least busy and map IP
translations to that machine. It should be noted that load balancing is commonly achieved
through proprietary methods and the servers need to communicate their availability to the


. 45
( 132 .)