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.
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.
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
- 3GPP TS 38.323 5G; NR; Packet Data Convergence Protocol (PDCP) Specification
- 3GPP TS 38.331 5G; NR; Radio Resource Control (RRC) Specification
Related Posts
- 5G Voice Services Implementation Options
- Voice over NR Call Flow
- VoNR Control Plane KPIs – Key Performance Indicator
- 5G Standalone Mode Registration-Attach Call Flow
- 5G RAN and 5GC Network Slice Signaling
- 5G SA Handover – Inter gNB-DU and Intra gNB-CU Handover