IP Header compression in UMTS network
description
Transcript of IP Header compression in UMTS network
IP Header compression in UMTS network
Thesis Work Presentation 14.02.2006
Author: Jukka RaunioSupervisor: Prof. Raimo KantolaInstructor: 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 life-time 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 ConsEasy to implementCompression of IP/TCP headers
Not robust enough in a case of a packet lossNo direct support for the compression of RTP packetsRelies 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 ConsRobustnessQuick context resynchronizationImproved encoding scheme for dynamical header fields
ComplexityRequires 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
0
0.5
1
1.5
2
2.5
3
3.5
ipv4/udp ipv4/tcp ipv6/udp ipv6/tcp
compressdecompress
Measurements
Packet size effects on the execution time
0
0.5
1
1.5
2
2.5
3
3.5
0 200 400 600 800 1000 1200 1400 1600
Packet Size [bytes]
Exe
cuti
on
Tim
e
IPv4/TCP IPv4/UDP IPv6/TCP IPv6/UDP
Measurements
Compiler optimization results
0
0.5
1
1.5
2
2.5
3
3.5
0 1 2 3Optimization Level
Compress
Decompress
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.
0
0.5
1
1.5
2
2.5
1 2 3 4Memory Arrangement
Compress
Decompress
1. The code and libs are completely in the external memory
2. Libs are located in the internal memory, code in the external
3. Libs and compress and decompress files in internal memory, others in the external memory
4. Everything in the internal
memory
Thank you!