Robust Header Compression – ROHC

ROHC is a header compression protocol/algorithm that can be used compress the header of different IP packets. In normal case without compression  IPv4 header is 40 bytes and IPv6 header is 60 bytes but with the help of ROHC compression these header can be compressed to 1 or 3 bytes.

Why Header Compression is Required:

The IP protocol is the choice of transport protocol for wired and wireless networks. As the networks grow to provide more bandwidth for the applications, services and the consumers of these applications and services, all compete to get bandwidth. For network operators it is important to offer a high quality of service (QoS) in order to attract more customers and encourage them to use their network as much as possible to achieving higher Average Revenue Rer User (ARPU).

In services and applications like Voice over IP, interactive games, messaging etc, the payload of the IP packets is almost of the same size or even smaller than the header. In end-to-end connection where it is consist of multiple hops, these protocol headers are extremely important but over just one link (hop-to-hop) these headers can be compressed and must be uncompressed at the other end. In many cases these header can compress these headers upto 90% and thus save the bandwidth and use the expensive resource efficiently. IP header compression also provides other important benefits, such as reduction in packet loss and improved interactive response time.

How is works:

1. At start of a session , the transmitter and receiver sends the full header information with out any compression
2. Both transmitter and receiver extract and store the information
3. for all further interaction, the transmitter sends only those information that is different from the information exchange at the very first transaction. As there lots of information in header remains static during the whole session, only small part is changing which is only 1 or 3 byte. Transmitting only changing part is the compressing the header.
4. Further Compress payload and other part of PDU/SDU.

To make it more clear let’s take example of IPv4 and UDP datagram, below picture show the header information for both

by looking on the above picture one could easy find out which part can change and which part remains unchanged. For example, Source IP, Destination IP, Version, Header Length, Type of Service, Source Port, Destination Port will remain static for a transaction. Simply by not transmitting this information for further transaction, the header size reduce significantly.

Other part like checksum and data can also be compressed with the ROHC algorithm.

ROHC in LTE

The ROHC function in LTE is part of Layer-2 at the user plane of the UE and eNB. Both UE and eNB behave as a compressor and decompressor for the user-plane packets in DL and UL. The compression efficiency depends on the ROHC operating mode and the variations in the dynamic part of the packet headers at the application layer. A header can be compressed to one byte with ROHC, which efficiently reduces the voice packet size.

ROHC in LTE operates in following three modes, the reliability of these modes and overheads used for transmitting feedback are different

• U-Mode (Unidirectional): In U-Mode, packets can only be sent from the compressor to the de-compressor, with
  no mandatory feedback channel. U-Mode has the lowest reliability but requires the minimum overhead for feedback
• O-Mode (Bidirectional Optimistic): In O-Mode, the decompressor can send feedback to indicate failed decompression or successful context update so it provides higher reliability than U-Mode but it generates less
  feedback compared to R-Mode
• R-Mode (Bidirectional Reliable): In R-Mode, context synchronization between the compressor and de-compressor
  are ensured only by the feedback. That is, the compressor sends the context updating packets repeatedly until
  acknowledgment is received from the de-compressor. Therefore, R-Mode provides the highest reliability but
  generates the maximum overhead due to the mandatory acknowledgment.

ROHC Profiles

ROHC is managed under RFC 3095 and with reference to it, there are four different types of ROHC profiles.

• Profile 0 (ROHC Uncompressed) : Compresses packets, which cannot be compressed by any of the below 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

Where as per 3GPP specification 36.323 there are following profiles are defined.

ROHC with VOLTE

ROHC can be applied to any application where we have very frequent transaction of small packets like voice over IP, interactive games, messaging. As here we are talking about LTE and Voice i.e. VoLTE, ROHC would be very useful for VoLTE application as it have a lot of small data carried by huge IP packets. For example, there can be a cases where only around 32 bytes of voice data (coded data) carried with a 60 bytes of header. In this case, only header parts takes more resources than the real data so this kind of packet can be a good candidate for ROHC.

As we aware, VoLTE has two types of packets, one for SIP signaling and the other voice traffic packet. The voice traffic  tend to be a very small data size but have very frequent transmission. So ROHC can be a very efficient solution to save network resources. Where as for SIP signaling packets are relatively large comparing to header size and not very frequent transmission so header compression may not be so efficient because SIP signaling packet. Although, even in SIP packets case we can save a little bit of resource, but the processing overhead resulted by header compression can be even bigger which is not a wise solution. Hence, ROHC does not apply to SIP signaling message packet in real scenarios.

ROHC Signalling:

The eNodeB get know about if a UE support ROHC using the UE capability information as shown below.

when ROHC is activated at eNodeB it informs UE using RRC reconfiguration message that this Data Radio Bearer (DRB).

References:

1. The concept of robust header compression, ROHC White paper
2. 3GPP 36.331 Radio Resource Control

Related Posts:

• VoLTE Cell Capacity- Calculating Packet Size, PRBs and No. of Users
• Voice Codec Options for VoLTE Services
• VoLTE SIP Methods, Response Codes and Details
• TTI Bundling for better HARQ and Latency
• Robust Header Compression – ROHC