VoNR with Robust Header Compression (ROHC)

VONR ROHC

Voice Service in 5G SA, VoNR can use ROHC to compress the headers of voice packets. ROHC helps reduce header overheads of voice packets on radio links, which helps in lowering BER, shortening delay, and reducing radio resource (RBs) consumption. ROHC can be used for both IPv4 and IPv6 protocols headers.

ROHC with VoNR

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 NR and Voice i.e. VoNR, ROHC would be very useful for VoNR 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, VoNR has two types of packets, one for SIP signaling and the other voice traffic packet (RTP). 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 (RBs). 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 Profiles – ROHC Category

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 38.323 there are 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
0x0103 ESP/IP RFC 5225
0x0104 IP RFC 5225

ROHC High Level Procedure

When the  ROHC feature is enabled enabled, the gNB starts the ROHC procedure as shown in below figure. when a UE initiates VoNR Call, the gNB determines the intersection of profiles supported by the UE before negotiating the maximum number of ROHC contexts including compression and decompression characteristics with the UE.

rohc-category

After ROHC is started, the compressor at the transmit (TX) end compresses the headers of voice packets, and the decompressor at the receive (RX) end restores the headers. Figure below shows the process of ROHC that uses profile 0x0001.

rohc

The specific process is as follows:

  • The compressor sends header-compressed data packets.
  • The compressor and decompressor maintain the context at the TX and RX ends respectively to ensure the context consistency through negotiation.
  • The decompressor restores the packet headers based on the context.

This function enables the decompressor to inform the compressor of successful or failed context synchronization. If context synchronization fails, the compressor sends the packet carrying the context repeatedly until context synchronization is successful. If the number of consecutive cyclic redundancy check (CRC) error packets received by the decompressor is greater than the threshold for exiting ROHC, ROHC is disabled.

RoHC Management During Handover

For an intra-cell (Inter Beam Mobility) handover, ROHC parameters remain unchanged and do not need to be renegotiated. For an inter-gNB inter-cell handover, ROHC parameters must be renegotiated as follows:

  • Source gNB sends a Handover Request message carrying the UE’s ROHC capability information to the target gNB
  • Target gNB sends a Handover Request Acknowledge carrying new ROHC parameters to the source gNB
  • Source gNB informs the UE of the new ROHC parameters sent by the target gNB through RRC reconfiguration

For an intra-gNB inter-cell handover, ROHC parameters must be renegotiated. The source cell informs the UE of the new ROHC parameters of the target cell through RRC reconfiguration.

5G UE ROHC Signaling

UE capability indicating all profiles supported by UE for RoHC

DRB Configuration with ROHC enabled

DRB Configuration without ROHC enabled

References

Related Posts



You may also like...