IP Header compression in UMTS network
Thesis Work Presentation 14.02.2006
Author: Jukka Raunio
Supervisor: Prof. Raimo Kantola
Instructor: M. Sc. Antti Lehtonen
Content






Background
Objectives & methodology
Header Compression in UMTS network
Header Compression mechanisms
DSP processor
Results
Background




The main service provided to the mobile users have
traditionally been only speech
Currently the mobile equipment supports also the use
of the Internet
IP telephony has also gained momentum thanks to
improved technical solutions
The problem in packet switched connections over the
radio interface of the mobile network is the poor
bandwidth efficiency caused by the header overhead
-for example a common size of TCP segments for
bulk transfers over medium-speed links is 512
octets and when this packet tunneled over
IPv6, the IPv6/IPv6/TCP header is 100 octets
leading to header overhead of 19,5%
Objectives & methodology
Objectives:
 Study the header compression mechanism
 Implement the Internet Protocol Header Compression
[RFC2507] mechanism on DSP
 Study the effects of the mechanism on the DSP
Methodology:
 Literature study based on the essential RFCs, the 3GPP
specifications and other available material.
 Measuring the implemented mechanism on the DSP
Header compression fundamentals


Header compression can be done because:
-much of the header information stays the same over the lifetime of a
packet stream
-some changing fields change with a small or a predictable
value and thus
incremental coding can be used e.g. TCP
sequence number
-only fields that change often and randomly need to be carried
in every
packet e.g. checksums
-values of some fields can be inferred for example from the link
layer
implementation
e.g. the length of
the packet
The general principle of header compression is to occasionally
send a packet with a full header; subsequent compressed
headers refer to the context established by the full header and
may contain incremental changes to the context.
Header compression fundamentals


The context is basically the uncompressed version of the last
header sent (compressor) or received (decompressor) over the
link.
A context identifier (CID) is a small unique number identifying
the context that should be used to decompress a compressed
header an it is carried in full headers and compressed headers.
Header compression benefits





Improve interactive response time
-achieved by sending smaller packets
Allow using small packets for bulk data with good line efficiency
-This is important when interactive (for example Telnet) and
bulk traffic (for example FTP) is mixed because the bulk data
should be carried in small packets to decrease the waiting time
when a packet with interactive data is caught behind a bulk
data packet
Allow using small packets for delay sensitive low data-rate
traffic
-Header compression can reduce the bandwidth needed for
headers significantly
Decrease header overhead
Reduce packet loss rate over lossy links
-Fewer bits are sent per packet and thus the packet loss rate
will be lower for a given bit-error rate
Header compression in UMTS network


In UMTS network the header compression is performed between the
User Equipment and the Radio Network Controller
The reason why the header compression is not done for example in the
node B is that the data encryption and the Macro Diversity Combining
(MDC) are done in the RNC.
Header compression mechanisms


UMTS network user plane protocol stack:
3GPP specifies two different header compression
mechanisms to be used on the Packet Data Convergence
Protocol (PDCP) layer:
-Internet Protocol Header Compression (IPHC)
-RObust Header Compression (ROHC) specified
Internet Protocol Header Compression




Specified in the RFC 2507
Can be applied to of IPv6 base and extension headers, IPv4
headers, TCP and UDP headers, and encapsulated IPv6 and
IPv4 headers
More simple of the two header compression mechanisms
The packets are classified into five categories:
-FULL_HEADER is used when a context is generated or
updated in the decompressor. The packet is similar to a
normal full header except that it contains a CID coded into
the length field of the IP header
-COMPRESSED_NON_TCP indicates a non-TCP packet with
compressed header
Internet Protocol Header Compression
-COMPRESSED_TCP packet contains a compressed
TCP packet containing a CID, a flag octet telling which
fields have changed since the previous compressed
packet, and the changed values encoded as a
difference from the previous value
-COMPRESSED_TCP_NO_DELTA indicates a packet
with a compressed TCP header where all fields that
are normally sent as the difference to the previous
value are instead sent as they are in the original
header.
-CONTEXT_STATE is a packet that may be used to
speed up the repair of the TCP streams over a links
where the decompressor can send packets to the
compressor.
Example compression of a IPv4/TCP
packet

The classification of the IPv4/TCP
header fields:
Internet Protocol Header Compression

The summarized gain of the header compression on
the IPHC:
Packet type
Header
size
(octets)
Minimum
compressed header
size (octets)
Max. compression gain [%]
IPv4/TCP
40
4
90.00
IPv4/UDP
28
2
92.86
IPv6/TCP
60
4
93.33
IPv6/UDP
68
4
91.67
Internet Protocol Header Compression

Summary of the pros and cons of the
IPHC
Pros
Cons
Easy to implement
Compression of IP/TCP
headers
Not robust enough in a case
of a packet loss
No direct support for the
compression of RTP packets
Relies on the use underlying
link layer to give the length of
the packet
Robust Header Compression





ROHC is specified in RFC 3095
Supports currently the compression of IP/UDP,
IP/UDP/RTP and IP/ESP packets
ROHC is meant to be used mainly with streams
containing real-time data and it is developed to be fault
tolerant even in links with higher error rates
The robustness is achieved with efficient communication
between the compressor and the decompressor
ROHC can be characterized as an interaction between
two state machines, the compressor machine and the
decompressor machine
Robust Header Compression




ROHC contains three different operational
modes: Unidirectional, Optimistic Bidirectional
and Reliable Bidirectional mode. The mode
specifies the way that the compressor and
decompressor states transitions are made.
Compressor and decompressor each have
three different states that control what kind
of packets are transmitted in each.
Compressor states: Initialization and Refresh
(IR), First Order (FO) and Second Order (SO).
Decompressor states: No Context, Static
Contexts and Full Context
Robust header Compression
Robust Header Compression

Pros and cons of Robust Header Compression
Pros
Cons
Robustness
Quick context
resynchronization
Improved
encoding scheme
for dynamical
header fields
Complexity
Requires significant
processing/memory
resources (compared
to IPHC)
Emerging standard
Measurements



The aim of the measurements was study the feasibility of the IPHC
mechanism on a Digital Signal Processor
The implementation and the measurements of the IPHC was done on
the Freescale MSC8101 DSP
The implementation was coded with the C-language
Measurements

The execution time measurements. The values of the all measurements
are scaled as a relative difference to the smallest value
3.5
3
2.5
2
compress
decompress
1.5
1
0.5
0
ipv4/udp
ipv4/tcp
ipv6/udp
ipv6/tcp
Measurements
Packet size effects on the execution time
3.5
3
2.5
Execution Time

2
1.5
1
0.5
0
0
200
400
600
800
1000
1200
Packet Size [bytes]
IPv4/TCP
IPv4/UDP
IPv6/TCP
IPv6/UDP
1400
1600
Measurements

Compiler optimization results
3.5
3
2.5
2
Compress
Decompress
1.5
1
0.5
0
0
1
2
Optimization Level
3
Level 0 code is not optimized at all and so the
code produced is linear assembly.
Level 1 option performs all target
independent optimizations, such as function
inlining.
Level 2 optimization is the first optimization
level that produces parallel assembly
language code. Parallel assembly code is code
where instructions are performed in parallel,
when it is possible. Parallelization is possible
only when there are no dependencies
between the instructions. All other target
specific optimizations are also used.
Level 3 uses the same optimizations as level
2, but now global register allocation is used.
Register allocation is an optimization that
allocates the virtual registers to physical
registers or memory slots, attempting to
minimize the transfers from memory to
registers.
Measurements

Memory optimization is a way to optimize the code by locating parts
of the code either in the internal or the external memory.
2.5
1.
2
2.
1.5
Compress
Decompress
1
3.
0.5
0
1
2
3
Memory Arrangement
4
4.
The code and libs are completely
in the external memory
Libs are located in the internal
memory, code in the external
Libs and compress and
decompress files in internal
memory, others in the external
memory
Everything in the internal
memory
Thank you!