11/15/2017 ShareTechnote
LTE Quick Reference Go Back To Index Home : [Link]
ROHC (Robust Header Compression)
ROHC is a kind of algorithm to compress the header of various IP packets. In case of IPv4, the size of uncompressed
IP header is 40 bytes and in case of IPv6, the size of uncompressed IP header is 60 bytes.
Only 40 bytes and 60 bytes ? It sounds pretty small. Why do these matters ?
If it is ordinary packet application like file transfer or browsing, it would not be a big issue since the size of data being
transferred would be very huge comparing to the size of header. So the overhead created by IP header would not be
a big issue. But in some applications (e.g, VoIP, short message, gaming etc) the size of data being transferred tend
to be small and they generate very frequent transactions, in this case overhead created by IP header gets very large.
In this case, it would be huge benefit if we can come up with any method to reduce the size of IP header and ROHC is
one of these method defined by RFC 3095. Ideal compression rate of ROHC is to reduce the size of header (40 or 60
bytes in original size) to only 1 or 2 bytes.
Overall Logic of Header Compression
Component (State) of ROHC Statemachine -Compressor
Component (State) of ROHC Statemachine - Decompressor
Component (State) of ROHC Statemachine - Mode of Operation
Component (State) of ROHC Statemachine - Combined
ROHC Profiles
ROHC Modes
ROHC in LTE
Possible application : VoLTE
UE Capability Information for ROHC
RRC Connection Reconfiguration for ROHC
An Example : ROHC Compression - VoLTE
An Example : ROHC UnCompression - VoLTE
< Overall Logic of Header Compression >
Basic idea of this compression method is pretty simple which can be described as follows.
i) At the start of a session (the initiation state), the transmitter and reciever sends the full size header without
any compression.
ii) From step i), both transmitter and reciever extract all the information from the header and store them.
iii) After the initial transaction, the transmitter sends only those information that is different from the header
information exchanged at the initial transaction. (Since a lot of information in the header would not change
during the whole session, the size of changing part would become very small. So transmitting only the
changing part would create the effect like data compression).
iv) Now perform real compression for the data still remaining after step iii).
For example, let's take a look at IP/UDP header. It would look as follows.
[Link] 1/6
11/15/2017 ShareTechnote
Out of all these information included in the header, which part do you think would not change during the session ? My
guess is as follows.
i) Source IP Address
ii) Destination IP Address
iii) Version
iv) IHL
v) Type of Service
vi) Source Port
vii) Destination Port
Simply removing these information would decrease the size of header in very large degree. Those engineers who
never get satisfied wanted to go even further and they came up with a lot of additional ideas which can reduce the
size of the changing part (e.g, Checksum etc) and the collection of all of these ideas were packaged into a single
specification called ROHC.
< Component (State) of ROHC Statemachine -Compressor >
ROHC has three main states as illustrated below. Try to correlate these states with the overall algorithm description
that I mentioned above.
< Component (State) of ROHC Statemachine - Decompressor >
< Component (State) of ROHC Statemachine - Mode of Operation >
[Link] 2/6
11/15/2017 ShareTechnote
< Component (State) of ROHC Statemachine - Combined >
< ROHC Profiles >
There are four different ROHC Profiles defined in RFC 3095 as follows.
Profile 0 (ROHC Uncompressed) : Compresses packets, which cannot be compressed by any of the following profiles
Profile 1 (ROHC RTP) : Compresses packets with IP/UDP/RTP protocol headers
Profile 2 (ROHC UDP) : Compresses packets with IP/UDP protocol headers
Profile 3 (ROHC ESP) : Compresses packets with IP/ESP protocol headers
In 3GPP 36.323 (Table [Link]: Supported header compression protocols and profiles) , Following profiles are
defined.
Profile Identifier Usage Reference
0x0000 No compression RFC 4995
0x0001 RTP/UDP/IP RFC 3095, RFC 4815
0x0002 UDP/IP RFC 3095, RFC 4815
0x0003 ESP/IP RFC 3095, RFC 4815
0x0004 IP RFC 3843, RFC 4815
0x0006 TCP/IP RFC 4996
0x0101 RTP/UDP/IP RFC 5225
0x0102 UDP/IP RFC 5225
[Link] 3/6
11/15/2017 ShareTechnote
0x0103 ESP/IP RFC 5225
0x0104 IP RFC 5225
< ROHC Modes >
The ROHC scheme has three modes of operation, called Unidirectional, Bidirectional Optimistic, and Bidirectional
Reliable mode.
Which mode would be the best one in a certain situation depends on the characteristics of the environment of the
compression protocol, such as feedback abilities,error probabilities and distributions, effects of header size variation,
etc. All ROHC implementations MUST implement and support all three modes of operation.
For the details, I recommed the RFC 3095 or a good white paper at
[Link]
ROHC in LTE
< Possible application : VoLTE >
One of the applications for which people are most actively talking about ROHC would be VoLTE since there can be a
lot of small data chunck carried by huge IP packets. For example, there can be a cases where only around 30 bytes
of voice data (coded data) carried with around 60 bytes of header. In this case, only header parts takes more
resources than the real data itself. So this kind of packet can be a good candiate for ROHC.
As you know, in VoLTE, you would see two kinds of packets. One of them is SIP Signaling packet and the other one
would be voice traffic packet. As I mentioned above, the voice traffic part tend to be a very small data size but cause
very frequent transmission. So ROHC can be a very efficient solution to save network resources. But for SIP signaling
part, the header compression may not be so efficient because the size of SIP signaling packet tend to be relatively
huge comparing to header size. Of course, even in this case you can save a little bit of resource, but the processing
overhead caused by header compression processing can be even bigger. So normally, ROHC does not apply to SIP
signaling message packet.
< UE Capability Information for ROHC >
c1: ueCapabilityInformation-r8 (0)
ueCapabilityInformation-r8
ue-CapabilityRAT-ContainerList: 2 items
Item 0
UE-CapabilityRAT-Container
rat-Type: eutra (0)
ueCapabilityRAT-Container: c51800304184200e1f8dfe1f8dfe1f8dfe1f8dfdfc37f2ea...
UE-EUTRA-Capability
accessStratumRelease: rel9 (1)
ue-Category: 3
pdcp-Parameters
supportedROHC-Profiles
...1 .... profile0x0001: True
.... 1... profile0x0002: True
.... .0.. profile0x0003: False
.... ..0. profile0x0004: False
.... ...0 profile0x0006: False
0... .... profile0x0101: False
.0.. .... profile0x0102: False
..0. .... profile0x0103: False
...0 .... profile0x0104: False
< RRC Connection Reconfiguration for ROHC >
c1: rrcConnectionReconfiguration-r8 (0)
rrcConnectionReconfiguration-r8
radioResourceConfigDedicated
drb-ToAddModList: 1 item
Item 0
DRB-ToAddMod
drb-Identity: 1
pdcp-Config
rlc-AM
...0 .... statusReportRequired: False
headerCompression: rohc (1)
rohc
profiles
.... ...1 profile0x0001: True
1... .... profile0x0002: True
[Link] 4/6
11/15/2017 ShareTechnote
.0.. .... profile0x0003: False
..0. .... profile0x0004: False
...0 .... profile0x0006: False
.... 0... profile0x0101: False
.... .0.. profile0x0102: False
.... ..0. profile0x0103: False
.... ...0 profile0x0104: False
< An Example : ROHC Compression - VoLTE >
< An Example : ROHC UnCompression - VoLTE >
[Link] 5/6
11/15/2017 ShareTechnote
[Link] 6/6