|
4G/LTE - Header Compression |
||||||||||||||||||||||||||||||||||
|
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 >
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.
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 >
< Component (State) of ROHC Statemachine - Combined >
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 5.5.1.1: Supported header compression protocols and profiles) , Following profiles are defined.
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 http://www.effnet.com/sites/effnet/pdf/uk/Whitepaper_Robust_Header_Compression.pdf
< 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 .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 >
|
||||||||||||||||||||||||||||||||||
